home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1357.txt < prev    next >
Text File  |  1996-05-07  |  26KB  |  411 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           D. Cohen Request For Comments: 1357                                        Editor                                                                      ISI                                                                July 1992 
  8.  
  9.               A Format for E-mailing Bibliographic Records 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo provides information for the Internet community.    It does not specify an Internet standard.  Distribution of    this memo is unlimited. 
  14.  
  15. Abstract 
  16.  
  17.    This memo defines a format for E-mailing bibliographic records of    technical reports.  It is intended to accelerate the dissemination    of information about new Computer Science Technical Reports (CS-TR). 
  18.  
  19. INTRODUCTION ------------ 
  20.  
  21.    Many Computer Science R&D organizations routinely announce new    technical reports by mailing (via the postal services) the    bibliographic records of these reports. 
  22.  
  23.    These mailings have non-trivial cost and delay.  In addition, their    recipients cannot conveniently file them, electronically, for later    retrieval and searches. 
  24.  
  25.    Therefore, it is suggested that the publishing organizations would    e-mail these announcements by using the following format. 
  26.  
  27.    Organizations may automate to any degree (or not at all) both the    creation of these records (about their own publications) and the    handling of the records received from other organizations. 
  28.  
  29.    This format is designed to be simple, for people and for machines,    to be easy to read ("human readable") and create without any special    programs, and to be compatible with E-mail. 
  30.  
  31.    This format defines how bibliographic records are to be transmitted.    It does not define what to do with them when received. 
  32.  
  33.    This format is a "tagged" format with self-explaining alphabetic    tags. It should be possible to prepare and to read bibliographic    records using any text editor, without any special programs. 
  34.  
  35.  
  36.  
  37.  Cohen (ed.)                                                     [Page 1] 
  38.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  39.  
  40.     This format was developed with considerable help and involvement of    Computer Science and Library personnel from several organizations,    including CMU, CNRI, Cornell, ISI, Meridian, MIT, Stanford, and UC.    Key contributions were provided by Jerry Saltzer of MIT, and Larry    Lannom of Meridian.  The initial draft was prepared by Danny Cohen    and Larry Miller of ISI. 
  41.  
  42.    The use of this format is encouraged.  There are no limitations on    its use. 
  43.  
  44.  THE INFORMATION FIELDS ---------------------- 
  45.  
  46.    The various fields should follow the format described below. 
  47.  
  48.    <M> means Mandatory; a record without it is invalid.    <O> means Optional. 
  49.  
  50.    The tags (aka Field-IDs) are shown in upper case. 
  51.  
  52.            <M>  BIB-VERSION of this bibliographic records format            <M>  ID            <M>  ENTRY date            <O>  ORGANIZATION            <O>  TITLE            <O>  TYPE            <O>  REVISION            <O>  AUTHOR            <O>  CORP-AUTHOR            <O>  CONTACT for the author(s)            <O>  DATE of publication            <O>  PAGES count            <O>  COPYRIGHT, permissions and disclaimers            <O>  RETRIEVAL information            <O>  CR-CATEGORY            <O>  PERIOD            <O>  SERIES            <O>  FUNDING organization(s)            <O>  MONITORING organization(s)            <O>  CONTRACT number(s)            <O>  GRANT number(s)            <O>  LANGUAGE name            <O>  NOTES            <O>  ABSTRACT            <M>  END 
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Cohen (ed.)                                                     [Page 2] 
  59.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  60.  
  61.  META FORMAT ----------- 
  62.  
  63.    * Keep It Simple. 
  64.  
  65.    * One bibliographic record for each publication, where a      "publication" is whatever the publishing institution defines      as such. 
  66.  
  67.    * A record contains several fields. 
  68.  
  69.    * Each field starts with its tag (aka the field-ID) which is a      reserved identifier (containing no separators) at the beginning      of a new line with or without spaces before it), followed by two      colons ("::"), followed by the field data. 
  70.  
  71.    * Continuation lines:  Lines are limited to 79 characters.  When      needed, fields may continue over several lines, with an implied      space in between.  In order to simplify the use no special marking      is used to indicate continuation line.  Hence, fields are      terminated by a line that starts (apart from white space) with      a word followed by two colons.  Except for the "END::" that is      terminated by the end of line.)  For improved human readability      it is suggested to start continuation lines with some spaces. 
  72.  
  73.    * Several fields are mandatory and must appear in the record.  All      fields (unless specifically not permitted to) may be in any order      and may be repeated as needed (e.g., the AUTHOR field).  The order      of the repeated fields is always preserved. 
  74.  
  75.    * Only printable ASCII characters may be used.  Hence, the      permissible characters are ASCII codes 040 (Space) through 176(~)      and line breaks which are \012 (LF) or \012\015 (CRLF).  Empty      lines indicate paragraph break.  \009 (tab) must be replaced by      spaces before submission.  This specifically forbids tabs, null      characters, DEL, backspaces, etc.  (i.e., if used, the record is      invalid.) 
  76.  
  77.    Throughout this document the word "publisher" means the publishing    organization of a report (e.g., a university or a department    thereof), not necessarily an organization authorized to issue ISBN    numbers. 
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87. Cohen (ed.)                                                     [Page 3] 
  88.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  89.  
  90.                                  EXAMPLE -----------------------------------------------------------------------  BIB-VERSION:: CS-TR-v2.0           ID:: OUKS//CS-TR-91-123        ENTRY:: January 15, 1992 ORGANIZATION:: Oceanview University, Kansas, Computer Science        TITLE:: The Computerization of Oceanview with High                    Speed Fiber Optics Communication         TYPE:: Technical Report     REVISION:: 2, FTP retrieval information added       AUTHOR:: Finnegan, James A.      CONTACT:: Prof. J. A. Finnegan, CS Dept, Oceanview Univ, Oceanview,                    KS 54321  Tel: 913-456-7890  <Finnegan@cs.ouks.edu>       AUTHOR:: Pooh, Winnie The      CONTACT:: 100 Aker Wood         DATE:: December 1991        PAGES:: 48    COPYRIGHT:: Copyright for the report (c) 1991, by J. A. Finnegan.                    All rights reserved.  Permission is granted for any                    academic use of the report.    RETRIEVAL:: For full text with color pictures send a self-addressed                    stamped envelope to Prof. J. A. Finnegan, CS Dept,                    Oceanview University, Oceanview, KS 54321.    RETRIEVAL:: ASCII available via FTP from JUPITER.CS.OUKS.EDU with the                    pathname PUBS/computerization.txt.  Login with FTP,                    username ANONYMOUS and password GUEST.                    File size: 123,456 characters  CR-CATEGORY:: D.0  CR-CATEGORY:: C.2.2 Computer Sys Org, Communication nets, Net Protocols       SERIES:: Communication      FUNDING:: FAS     CONTRACT:: FAS-91-C-1234   MONITORING:: FNBO     LANGUAGE:: English        NOTES:: This report is the full version of the paper with the                same title in IEEE Trans ASSP Dec 1976 
  91.  
  92. ABSTRACT:: 
  93.  
  94. Many alchemists in the country work on important fusion problems. All of them cooperate and interact with each other through the scientific literature.  This scientific communication methodology has many advantages.  Timeliness is not one of them. 
  95.  
  96. END:: OUKS//CS-TR-91-123 ---------------------------- End of Example --------------------------- 
  97.  
  98.    For reference, the above example has about 1,750 characters (220    words) including about 250 characters (40 words) in the abstract. 
  99.  
  100.  Cohen (ed.)                                                     [Page 4] 
  101.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  102.  
  103.  THE ACTUAL FORMAT ----------------- 
  104.  
  105.    In the following double-quotes indicate complete strings.  They are    included only for grouping and are not expected to be used in the    actual records. 
  106.  
  107.    The term "Open Ended Format" in the following means arbitrary text. 
  108.  
  109.    The BIB-VERSION, ID, ENTRY, and END field must appear as the first,    second, third, and last fields, and may not be repeated in the    record.  All other fields may be repeated as needed. 
  110.  
  111.  BIB-VERSION (M) -- This is the first field of any record.  It is a         mandatory field.  It identifies the version of the format used         to create this bibliographic record. 
  112.  
  113.         BIB-VERSIONs that start with the letter X (case independent)         are considered experimental.  Bib-records sent with such a         BIB-VERSION should NOT be incorporated in the permanent database         of the recipient. 
  114.  
  115.         Using this version of this format, this field is always: 
  116.  
  117.         Format:   BIB-VERSION:: CS-TR-v2.0 
  118.  
  119.  ID (M) -- This is the second field of any record.  It is also a         mandatory field.  Its format is "ID:: XXX//YYY", where XXX is         the publisher-ID (the controlled symbol of the publisher)         and YYY is the ID (e.g., report number) of the publication as         assigned by the publisher.  This ID is typically printed on         the cover, and may contain slashes. 
  120.  
  121.         The organization symbols "DUMMY" and "TEST" (case independent)         and any organization symbol starting with <X> (case         independent) are reserved for test records that should NOT         be incorporated in the permanent database of the recipients. 
  122.  
  123.         Format:   ID:: <publisher-ID>//<free-text> 
  124.  
  125.         Example:  ID:: OUKS//CS-TR-91-123 
  126.  
  127.             **** See the note at the end regarding the ****             **** controlled symbols of the publishers ***** 
  128.  
  129.  
  130.  
  131.  
  132.  
  133. Cohen (ed.)                                                     [Page 5] 
  134.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  135.  
  136.  ENTRY (M) -- This is a mandatory field.  It is the date of creating this         bibliographic record. 
  137.  
  138.         The format for ENTRY date is "Month Day, Year".  The month must         be alphabetic (spelled out).    The "Day" is a 1- or 2-digit         number.  The "Year" is a 4-digit number. 
  139.  
  140.         Format:   ENTRY:: <date> 
  141.  
  142.         Example:  ENTRY:: January 15, 1992 
  143.  
  144.  ORGANIZATION (O) --  It is the full name spelled out (no acronyms,         please) of the publishing organization.  The use of this name         is controlled together with the controlled symbol of the         publisher (as discussed above for the ID field). 
  145.  
  146.         Avoid acronyms because there are many common acronyms, such as         ISI and USC.  Please provide it in ascending order, such as         "X University, Y Department" (not "Y Department, X University"). 
  147.  
  148.         Format:   ORGANIZATION:: <free-text> 
  149.  
  150.         Example:  ORGANIZATION:: Stanford University, Computer Science 
  151.  
  152.  TITLE (O) -- This is the title of the work as assigned by the author.         This field should include the complete title with all the         subtitles, if any. 
  153.  
  154.         If the publication has no title (e.g., in withdrawal), a blank         TITLE field should be included. 
  155.  
  156.         Format:   TITLE:: <free-text> 
  157.  
  158.         Example:  TITLE:: The Computerization of Oceanview with High                               Speed Fiber Optics Communication 
  159.  
  160.  TYPE (O) -- Indicates the type of publication (summary, final project         report, etc.) as assigned by the issuing organization. 
  161.  
  162.         Format:   TYPE:: <free-text> 
  163.  
  164.         Example:  TYPE:: Technical Report 
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  Cohen (ed.)                                                     [Page 6] 
  171.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  172.  
  173.  REVISION (O) -- Indicates that the current bibliographic record is         a revision of a previously issued record and is intended to         replace it.  Revision information consists of an integer         followed by a comma, and by text in an open ended format.         The revised bibliographic record should contain a complete         record for the publication, not just a list of changes to         the old record.  The default assumption is that a record is         not a revision (i.e., specify only if it is), with that integer         being zero. 
  174.  
  175.         The first token in this field is an integer revision number.         Higher numbers indicate later revisions.  Use the text to         describe the revision.  Reasons to send out a revised record         include an error in the original, change in the retrieval         information, or withdrawal (see below). 
  176.  
  177.         Format:  REVISION:: N, <free-text> 
  178.  
  179.         Example: REVISION:: 2, FTP retrieval information added 
  180.  
  181.      WITHDRAWING:  A withdrawal of a record is a special case of revising         it.  Hence, the standard way to withdraw records is by sending a         revision record with (at least) all the mandatory fields, and an         optional explanation in the NOTES field. 
  182.  
  183.         It is OK on withdrawal to eliminate the title, by not providing         the TITLE field it or by providing it with no text (blank). 
  184.  
  185.         Example for withdrawing a bibliographic record:: 
  186.  
  187.             BIB-VERSION::  CS-TR-v2.0             ID::           OUKS//CS-TR-91-123             ENTRY::        January 25, 1992             ORGANIZATION:: Oceanview University, Kansas, Computer Science             TITLE::             REVISION::     4, withdrawn             NOTES::        Withdrawn, found to be irrelevant             END::          OUKS//CS-TR-91-123 
  188.  
  189.         This new record will replace all the fields of the previous         record for that publication.  In this example it will eliminate         the title, the retrieval information provided earlier, and not         mention the authors. 
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197. Cohen (ed.)                                                     [Page 7] 
  198.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  199.  
  200.  AUTHOR (O) -- Personal names only.  Normal last name first inversion.         Editors should be listed here as well, identified with the         usual "(ed.)" as shown below in the last example. 
  201.  
  202.         If the report was not authored by a person (e.g., it was         authored by a committee or a panel) use CORP-AUTHOR (see below)         instead of AUTHOR. 
  203.  
  204.         Multiple authors are entered by using multiple lines, each in         the form of "AUTHOR:: <free-text>". 
  205.  
  206.         The system preserves the order of the authors. 
  207.  
  208.         Format:   AUTHOR:: <free-text> 
  209.  
  210.         Example:  AUTHOR:: Finnegan, James A.                   AUTHOR:: Pooh, Winnie The                   AUTHOR:: Lastname, Firstname (ed.) 
  211.  
  212.  CORP-AUTHOR (O) -- The corporate author (e.g., a committee or a         panel) that authored the report, which may be different from         the ORGANIZATION issuing the report. 
  213.  
  214.         In entering the corporate name please omit initial "the" or "a".         If it is really part of the name, please invert it. 
  215.  
  216.         Format:   CORP-AUTHOR:: <free-text> 
  217.  
  218.         Example:  CORP-AUTHOR:: Committee on long-range computing 
  219.  
  220.  CONTACT (O) -- The contact for the author(s).         Open-ended, most likely E-mail and postal addresses. 
  221.  
  222.         You may provide a CONTACT field for each author separately,         or for all the AUTHOR fields. 
  223.  
  224.         E-mail addresses should always be in "pointy brackets"         (as in the example below). 
  225.  
  226.         Format:   CONTACT:: <free-text> 
  227.  
  228.         Example:  CONTACT:: Prof. J. A. Finnegan, CS Dept, Oceanview                             Univ., Oceanview, Kansas, 54321                             Tel: 913-456-7890 <Finnegan@cs.ouks.edu> 
  229.  
  230.  
  231.  
  232.  
  233.  
  234. Cohen (ed.)                                                     [Page 8] 
  235.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  236.  
  237.  DATE (O) -- The publication date.  The formats are "Month Year" and         "Month Day, Year".  The month must be alphabetic (spelled out).         The "Day" is a 1- or 2-digit number.  The "Year" is a 4-digit         number. 
  238.  
  239.         Format:   DATE:: <date> 
  240.  
  241.         Example:  DATE:: January 1992         Example:  DATE:: January 15, 1992 
  242.  
  243.  PAGES (O) -- Total number of pages, without being too picky about it.         Final numbered page is actually preferred, if it is a reasonable         approximation to the total number of pages. 
  244.  
  245.         Format:   PAGES:: <number> 
  246.  
  247.         Example:  PAGES:: 48 
  248.  
  249.  COPYRIGHT (O) -- Copyright, permissions and disclaimers.  Open         ended format.  The COPYRIGHT field applies to the cited         report, rather than to the current bibliographic record.         On advice of counsel it is suggested that you seek the         advice of yours. 
  250.  
  251.         Format:  COPYRIGHT:: <free-text> 
  252.  
  253.         Example: COPYRIGHT:: Copyright for the report (c) 1991,                             by J. A. Finnegan.  All rights reserved.                             Permission is granted for any academic                             use of the report. 
  254.  
  255.  RETRIEVAL INFORMATION (O) -- Open-ended format describing how to get         a copy of the full text.  It may include anything from FTP         instructions to a variety of files (e.g., ASCII, TeX, and         PostScript) to "Send $4.50 to ..." or "Send E-mail to <X@Y>". 
  256.  
  257.         It is suggested to repeat this field for each retrieval option         (e.g., one line for the FTP instructions to the ASCII version,         and another for the PostScript version).  When offering files         like TeX all the related files (e.g., "\input mystyle") should         be included.  Please provide file sizes (in characters). 
  258.  
  259.         Means are not defined yet for providing the information needed         for automatic retrieval of files (such as via FTP).  They are         expected to be defined in the near future. 
  260.  
  261.  
  262.  
  263. Cohen (ed.)                                                     [Page 9] 
  264.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  265.  
  266.          No limitations are placed on the dissemination of the         bibliographic records.  If there are limitations on the         dissemination of the publication, it should be protected by         some means such as passwords.  This format does not address         this protection. 
  267.  
  268.         Format:  RETRIEVAL:: <free-text> 
  269.  
  270.         Example: RETRIEVAL:: For full text with color pictures send                              a self-addressed stamped envelope to                              Prof. J. A. Finnegan, CS Dept,                              Oceanview University, Oceanview, KS 54321.                  RETRIEVAL:: ASCII available via FTP from                              JUPITER.CS.OUKS.EDU with the pathname                              PUBS/computerization.txt.                              Login with FTP, username ANONYMOUS and                              password GUEST.                              File size: 123,456 characters 
  271.  
  272.  CR-CATEGORY (O) -- Specify the CR-category.  The CR-category (the         Computer Reviews Category) index (e.g., "B.3") should always be         included, optionally followed by the name of that category.  If         the name is specified it should be fully specified with parent         levels as needed to clarify it, as in the second example below.         Use multiple lines for multiple categories. 
  273.  
  274.         The January 1992 issue of CR has the full list of these         categories, with a detailed discussion of the CR Classification         System, and a full index.  Typically the full index appears in         every January issue, and the top two levels in every issue. 
  275.  
  276.         Format:   CR-CATEGORY:: <free-text> 
  277.  
  278.         Example:  CR-CATEGORY:: D.1 
  279.  
  280.         Example:  CR-CATEGORY:: B.3 Hardware, Memory Structures 
  281.  
  282.  PERIOD (O) -- Time period covered (date range).  Applicable primarily to         progress reports, etc.  Any format is acceptable, as long as the         two dates are separated with " to " (the word "to" surrounded by         spaces) and each date is in the format allowed for dates, as         described above for the date field. 
  283.  
  284.         Format:   PERIOD:: <date> to <date> 
  285.  
  286.         Example:  PERIOD:: January 1990 to March 1990 
  287.  
  288.  
  289.  
  290. Cohen (ed.)                                                    [Page 10] 
  291.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  292.  
  293.  SERIES (O) -- Series title, including volume number within series.         Open-ended format, with producing institution strongly         encouraged to be internally consistent. 
  294.  
  295.         Format:   SERIES:: <free-text> 
  296.  
  297.         Example:  SERIES:: Communication 
  298.  
  299.  FUNDING (O) -- The name(s) of the funding organization(s). 
  300.  
  301.         Format:   FUNDING:: <free-text> 
  302.  
  303.         Example:  FUNDING:: DARPA 
  304.  
  305.  MONITORING (O) -- The name(s) of the monitoring organization(s). 
  306.  
  307.         Format:   MONITORING:: <free-text> 
  308.  
  309.         Example:  MONITORING:: ONR 
  310.  
  311.  CONTRACT (O) -- The contract number(s). 
  312.  
  313.         Format:   CONTRACT:: <free-text> 
  314.  
  315.         Example:  CONTRACT:: MMA-90-23-456 
  316.  
  317.  GRANT (O) -- The grant number(s). 
  318.  
  319.         Format:   CONTRACT:: <free-text> 
  320.  
  321.         Example:  GRANT:: NASA-91-2345 
  322.  
  323.  LANGUAGE (O) -- The language in which the report is written.         Please use the full English name of that language. 
  324.  
  325.         Please include the Abstract in English, if possible. 
  326.  
  327.         If the language is not specified, English is assumed. 
  328.  
  329.         Format:   LANGUAGE:: <free-text> 
  330.  
  331.         Example:  LANGUAGE:: English 
  332.  
  333.  
  334.  
  335.  Cohen (ed.)                                                    [Page 11] 
  336.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  337.  
  338.  NOTES (O) -- Miscellaneous free text. 
  339.  
  340.         Format:   NOTES:: <free-text> 
  341.  
  342.         Example:  NOTES:: This report is the full version of the paper                           with the same title in IEEE Trans ASSP Dec                           1976 
  343.  
  344.  ABSTRACT (O) -- Highly recommended, but not mandatory.  Even though no         limit is defined for its length, it is suggested not to expect         applications to be able to handle more than 10,000 characters. 
  345.  
  346.         The ABSTRACT is expected to be used for subject searching since         titles are not enough.  Even if the report is not in English, an         English ABSTRACT is preferable.  If no formal abstract appears         on document, the producers of the bibliographic records are         encouraged to use pieces of the introduction, first paragraph,         etc. 
  347.  
  348.         Format:  ABSTRACT:: xxxx .............. xxxxxxxx                             xxxx .............. xxxxxxxx 
  349.  
  350.                             xxxx .............. xxxxxxxx                             xxxx .............. xxxxxxxx 
  351.  
  352.  END (M) -- This is a mandatory field.  It must be the last entry of a         record, identifying the record that it ends, by stating the same         ID that was used at the beginning of the records, in its "ID::". 
  353.  
  354.         Format:   END:: XXX 
  355.  
  356.         Example:  END:: OUKS//CS-TR-91-123 
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.              >>>>>>>   [END OF FORMAT DEFINITION]   <<<<<<< 
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374. Cohen (ed.)                                                    [Page 12] 
  375.  RFC 1357       Format for E-mailing Bibliographic Records      July 1992 
  376.  
  377.  A Note Regarding the Controlled Symbols of the Publishers 
  378.  
  379.    In order to avoid conflicts among the symbols of the publishing    organizations (the XXX part of the "ID:: XXX//YYY") it is suggested    that the various organizations that publish reports (such as    universities, departments, and laboratories) register their    <publisher-ID> symbols and names, in a way similar to the    registration of other key parameters and names in the Internet. 
  380.  
  381.    Danny Cohen <Cohen@ISI.EDU> of ISI, has agreed to coordinate this    registration for the publishers of Computer Science technical    reports.  It is suggested that before using this format the    publishing organizations would coordinate with him (by e-mail) their    symbols and the names of their organizations.  [Discussions are in    progress to have these publisher-IDs registered with the Internet    Assigned Numbers Authority (IANA) and listed in future editions of    the Assigned Numbers document.] 
  382.  
  383.    In order to help automated handling of the received bibliographic    records, it is expected that the producers of bibliographic records    will always use the same name, exactly, in the ORGANIZATION field. 
  384.  
  385.  Security Considerations 
  386.  
  387.    Security issues are not discussed in this memo. 
  388.  
  389.  Author's Address 
  390.  
  391.    Danny Cohen    USC - Information Sciences Institute    4676 Admiralty Way    Marina del Rey, California  90292-6695 
  392.  
  393.    Phone: 310-822-1511 
  394.  
  395.    Fax:   310-823-6714 
  396.  
  397.    EMail: Cohen@ISI.EDU 
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409. Cohen (ed.)                                                    [Page 13] 
  410.  
  411.