doc: Add RFC documents

1 files changed, 348 insertions, 0 deletions

diff --git a/doc/rfc/rfc807.txt b/doc/rfc/rfc807.txt
new file mode 100644
index 0000000..88f995a
--- /dev/null
+++ b/doc/rfc/rfc807.txt
@@ -0,0 +1,348 @@
+
+
+Network Working Group                                          J. Postel
+Request for Comments:  807                                           ISI
+                                                         9 February 1982
+
+
+
+                     Multimedia Mail Meeting Notes
+
+
+
+
+Introduction
+
+   A meeting was held at USC Information Sciences Institute on the 12th
+   of January 1982 to discuss multimedia mail issues and experiments.
+   The list of attendees is at the end of this memo.
+
+Overview:
+
+   This meeting was called to discuss common interests in multi-media
+   computer mail experiments, and to agree on some specific initial
+   experiments.
+
+Review of Status:
+
+   Review current status of multimedia efforts at CMU, ISI, MIT, COMSAT,
+   BBN, UCL, SRI.
+
+   CMU
+
+      Using PERQ, Quip for fax, LPCM vocoder from LL, will get NEC board
+      (3 chips) to replace vocoder.  Will have a stand alone voice I/O
+      device that operates at 2400 baud (not packetized). Not working on
+      IP/TCP.  Will use the IP and TCP from the BBN project. Already
+      using the BBN Jericho developed Pascal IP and CFTP. Interested in
+      word recognition of LPC digitized voice data. Planning to package
+      a synthesiser, an analyzer, and a pitch tracker on one board.
+
+   ISI
+
+      Using TOPS20 (code in BLISS10), and starting to use PERQ (code in
+      Pascal), RAPICOM 450 for fax.  Main interest is in the data
+      structuring and message transport protocols.
+
+   MIT
+
+      Using Apollos, will program in MDL.  Use of Apollos still limited
+      due to (1) MDL not completely implemented, (2) network interface
+      not yet available (waiting on multibus  to then interface to
+      Ethernet). Will get NEC CCITT fax machine. Looking into VAX+BBN
+      BitGraph for future.  Main work to date in  design for sharing
+      message data in a conceptualy centralized filing system.  Emphasis
+
+
+Postel                                                          [Page 1]
+
+
+
+Multi-Media Mail Meeting Notes                           9 February 1982
+
+
+      on efficient storage and manipulation of multirecipient messages,
+      enclosures, citations, etc.
+
+   COMSAT
+
+      Using small 11s, Rapicom 450 and 500 fax machines, also have some
+      LPC vocoders.  Substantial work has been done on encoding and
+      decoding both Rapicom 450 and CCITT T.4 fax data, and also on
+      manipulation of bitmap data (See RFC 803).
+
+   BBN
+
+      Using Jericho (code in Pascal). Will be building a prototype
+      system with the aim of investigating problems of data distribution
+      and privacy.  Trying to produce portable software currently in
+      Pascal but may switch to ADA in the distant future.  Have IP and
+      CFTP running, working on TCP. CFTP is a file transfer built
+      directly on IP.
+
+   UCL
+
+      Using LSI-11, Rapicom 450 fax machine, Grinell bitmap display.
+      May get PERQs (produced by ICL) in future.  Have done quite a lot
+      of work on encoding/decoding for the Rapicom 450, and in bitmap
+      manipulations (e.g., cleanup of noise, scaling, cut and paste).
+      Interests in the relation of other types of display protocols to
+      multimedia effort e.g., VIDEOTEXT and TELETEXT.
+
+   SRI
+
+      There are three multimedia mail projects at SRI,sponsored by DCEC,
+      ARPA, and NAVELEX.  SRI is a subcontractor (with Sytek and DTI) to
+      SDC in the DCEC program to produce protocol specifications for the
+      DoD.  SRI has written service specifications for a mail system
+      similar to RFC759+767 with security features added.  The ARPA
+      project is studying the issues involved in a multimedia mail
+      architecture based on RFC759+767, including negotiations,
+      envelopes, and multilevel security.  The NAVELEX project is
+      investigating user interfaces for command and control
+      workstations, including natural language access to a data base.
+      The plan is to use RFC759+767 data structures to communicate text
+      and graphics, implemented on Foonly F-5s running Tenex with
+      Foo-Vision displays.  The current choice for the graphics protocol
+      is Bisbey's GL2.
+
+
+
+
+
+
+
+Postel                                                          [Page 2]
+
+
+
+Multi-Media Mail Meeting Notes                           9 February 1982
+
+
+Discussion:
+
+   Coding/Decoding Algorithm:
+
+      We agree to use the encoding specified in the CCITT T.4
+      recommendation for the exchange of black and white bitmap data.
+
+   New Equipment:
+
+      It is reported that soon NEC will have CCITT T.4 Group 3 Fax
+      machines for about $15K.
+
+   NBS Mail Standard:
+
+      The possibility that the NBS Mail Format Standard is a workable
+      alternative to the RFC759+767 protocol is to be studied.  What is
+      the relationship between these standards?  Do we have comment on
+      the NBS Standard to submit to NBS?
+
+   Equipment Variations:
+
+      What happens if the receiver does not have equipment capable of
+      protraying some of the data (e.g., dosen't have a  LPC vocoder)?
+      There are three subtopics:  How many "standard" forms are
+      allowed?, What do you tell the user if you can't do it?, and How
+      does the cost of a medium (in memory or cpu cycles or portrayal
+      time) effect its use? The general feeling was that if there is
+      some type of data the receiving system can't portray, it should
+      simply tell the user "There is some data here I can't portray and
+      it's type is x.". The other aspects are items for further study.
+
+   Negotiation:
+
+      Does negotiation make sense in a mail system?  What are the kinds
+      of things to be negotiated?  One possiblity is to initially send
+      only pointers to the sections of a message, and have the recipient
+      system ask for the parts it can handle.  Does this make sense in a
+      message relaying environment?  Or for messsages with a fine scale
+      interleaving of media types?  This topic is for further study.
+
+   Enclosures, Pointers, Cross References:
+
+      This seems too complex to handle at this meeting, so for now send
+      the whole thing.  This is an item for further study.
+
+   Editing Multimedia Objects:
+
+      This is one of the most interesting parts of these research
+
+
+
+Postel                                                          [Page 3]
+
+
+
+Multi-Media Mail Meeting Notes                           9 February 1982
+
+
+      projects, so each group will develop their own techniques, and we
+      will compare notes.
+
+   Manipulation of Bitmaps:
+
+      The issues involve aspect ratios, cut and paste, rotation  and,
+      scaling. We need to compare notes and exchange algorithms.  An
+      item for further study.
+
+   Mailbox IDs and Control Information:
+
+      With different types of source hosts and destination host
+      (timsharing systems, personal computers) and different types of
+      mail delivery schemes (append to file, query database server), do
+      we have sufficient control mechanisms and addressing modes?  This
+      is an item for further study.
+
+   Storage and Transmission:
+
+      How do the requirements for memory, disk, cpu, and transmission
+      capacity differ for multimedia mail from text mail? This is an
+      item for further study.
+
+   Multimedia Virtual Message Format:
+
+      It is not clear that this is anything different than what is
+      specified by RFC759+767, but since it was not fully discussed it
+      is an item for further study.
+
+   Media Specific Protocols:
+
+      Specific format definitions are needed for each media.  This is an
+      item for further study.
+
+   Interfaces to Other Systems:
+
+      How do we interface this multimeda system to opther systems (e.g.,
+      TELETEXT, VIDEOTEXT), and to text only mail systems (e.g.,
+      ARPAMAIL, TELEMAIL, ONTYM).  This is an item for further study.
+
+An Experiment:
+
+   BITMAP-TEXT DOCUMENT EXCHANGE
+
+      Move the data between computers as a file, using any file transfer
+      method available.
+
+      The File is a complete RFC 759 Document.
+
+
+
+Postel                                                          [Page 4]
+
+
+
+Multi-Media Mail Meeting Notes                           9 February 1982
+
+
+      Bitmap data is in revised COMSAT Image Data Format.
+
+         Two compression types are to be used:
+
+            Raw Bitmap
+
+            CCITT Algorithm
+
+      Text data is in RFC767 Paragraph Format.
+
+Action Items:
+
+   Start a New Note Series
+
+      For the exchange of protocols, formats, algorithms, procedures,
+      and other information between the multiamedia mail projects.
+
+      By: Jon Postel
+
+      Due: 1-Feb-82
+
+   Update RFCs 759 & 767
+
+      To remove typos and clairfy ambiguities.
+
+      By: Jon Postel
+
+      Due: 1-Feb-82
+
+   Update "Image Data Structure" Memo
+
+      To be more generally for bitmaps and not so focused on fax only.
+
+      By: Anil Agarwal
+
+      Due: 1-Feb-82
+
+   Compare and Contrast NBS Mail Standard with RFC 759+767 Protocol
+
+      Would the NBS Mail Standard be an adaquate alternative to the RFC
+      759+767 approach?
+
+      By: each site
+
+      Due: Unspecified
+
+
+
+
+
+
+Postel                                                          [Page 5]
+
+
+
+Multi-Media Mail Meeting Notes                           9 February 1982
+
+
+   Issue the NBS Mail Standard as an RFC
+
+      To aid in wide consideration of it. (Where does the online file
+      come from?)
+
+      By: Jon Postel
+
+      Due: Unspecified
+
+   Report on the differences between the NBS Mail Standard and other
+   things.
+
+      What are the differences between the NBS standard and the
+      RFC759+767 protocol?, the IFIP plans?, the CCITT plans?, and the
+      ISO plans?
+
+      By: Debbie Deustch
+
+      Due: Unspecified
+
+   Demonstrate FAX-TEXT Document Exchange
+
+      This demonstration is to be ready before and repeated at the User
+      Interface Meeting at CMU.
+
+      By: all sites
+
+      Due: 19-20 April 82
+
+Attendees:
+
+   Duane A. Adams    DARPA/IPTO    Adams@ISI           (202) 694-8096
+   Vint Cerf         DARPA/IPTO    Cerf@ISI            (202) 694-3049
+   Harry Forsdick    BBN           Forsdick@BBN        (617) 497-3638
+   Bob Thomas        BBN           BThomas@BBND        (617) 497-3483
+   Gene Ball         CMU           Ball@CMUA           (412) 578-2569
+   Anil Agarwal      COMSAT        Agarwal@ISID        (301) 863-6103
+   David L. Mills    COMSAT        Mills@ISID          (202) 863-6092
+   Dave Lebling      MIT           PDL@MIT-XX          (617) 253-1440
+   Jon Postel        ISI           Postel@ISIF         (213) 822-1511
+   Greg Finn         ISI           Finn@ISIF           (213) 822-1511
+   Alan Katz         ISI           Katz@ISIF           (213) 822-1511
+   Carl Sunshine     ISI           Sunshine@ISIF       (213) 822-1511
+   David Elliott     SRI           wde@SRI-KL          (415) 859-4107
+   Andy Poggio       SRI           Poggio@SRI-Unix     (415) 859 5094
+   Zaw-Sing Su       SRI           ZSu@SRI-Unix        (415) 859-4576
+   Steve Kille       UCL           UCL-Netwiz@ISIE  (uk) (01)387-7050
+   Peter Kirstein    UCL           PKirstein@ISIA   (uk) (01)387-7050
+   Bill Tuck         UCL           UKSAT@ISIE       (uk) (01)387-7050
+
+
+Postel                                                          [Page 6]
+