RFC 767
Structured format for transmission of multi-media documents
RFC 767 🎀 A Structured Format for Transmission of Multi-Media Documents
Part 1 of 5 🌈
Okay bestie, RFC 767 is a classic 💜 It's titled A Structured Format for Transmission of Multi-Media Documents, it was written by Jonathan B. Postel, and it's dated August 1980 🦋 The author was at the Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291 (phone (213) 822-1511) 🌸 The title block doesn't name a category, and it doesn't list anything this document obsoletes or updates, so it's standing on its own ✨ There's also an editorial stamp on the first page, which I'm keeping exactly as written:
< INC-PROJECT, MMMSFS.NLS.21, >, 5-Sep-80 20:19 JBP ;;;;Preface 📝
This is the first edition of this format specification and should be treated as a request for comments, advice, and suggestions 🫶 A great deal of prior work has been done on computer aided message systems, and some of it is listed in the reference section. This specification was shaped by many discussions with members of the ARPA research community and others interested in developing computer aided message systems. The document was prepared as part of the ARPA sponsored Internetwork Concepts Research Project at ISI.
Jon Postel 💅
Table of Contents 🗂️
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1. Motivation ................................................... 1
1.2. Scope ........................................................ 1
1.3. Terminology .................................................. 1
1.4. Document Description ......................................... 2
1.5. Other Work ................................................... 2
2. SPECIFICATION .................................................... 3
2.1. Document ..................................................... 3
2.2. Message Objects ............................................. 5
2.3. Body Structures ............................................. 13
2.3.1. Simple Elements ........................................... 13
2.3.2. Structured Text ........................................... 13
2.3.3. NLS File Example .......................................... 13
2.3.4. Multimedia Structures ..................................... 15
2.3.5. The Media ................................................. 21
2.3.6. TEXT ...................................................... 22
2.3.7. VOICE ..................................................... 22
2.3.8. FACSIMILE ................................................. 23
2.3.9. GRAPHICS .................................................. 24
3. EXAMPLES & SCENARIOS ............................................ 25
Example 1: Text Example .......................................... 25
Example 2: Multimedia Example .................................... 28
REFERENCES .......................................................... 311. Introduction ✨
This document describes a format for transmitting structured data representations of multimedia documents 🎬 The format is meant to be used with the Internet Message Protocol in an internetwork message delivery system. That system transmits messages between processes in host computers called Message Processing Modules (MPMs). MPMs sit in several networks and together make up the internetwork message delivery system 🌐 The Internet Message Protocol defines a message as being made of an Identification, a Command, and a Document. This report defines the format of those Documents. The reader is assumed to be familiar with the Internet Message Protocol [1].
1.1. Motivation 💭
Computer applications are being built to interact with users through a variety of media: text, graphics, facsimile, and speech 🖼️ As computer devices become able to process multimedia information, it becomes useful to exchange that information between programs and users, through mechanisms including computer mail, and this is what the format is for.
1.2. Scope 🔭
This format is meant for transmitting multimedia documents in the internetwork message delivery system, but it's thought to have wider applicability too 🌈
1.3. Terminology 📖
Messages are routed by a process called the Message Processing Module, or MPM 🚦 Messages are created and consumed by User Interface Programs (UIPs), working together with users.
The basic unit transferred between MPMs is called a message. A message is made up of a transaction identifier (which uniquely identifies the message), a command (which contains the information needed for delivery), and a document. The document is a data structure 🧩
For a personal letter, the document body corresponds to the contents of the letter, and the document header corresponds to the date line, greeting, and signature 💌
For an inter-office memo, the document body corresponds to the text, and the document header corresponds to the header of the memo 🏢
The commands correspond to the information the Post Office or the mail room uses to route a letter or memo. Some of the information in the command is supplied by the UIP 📮
1.4. Document Description 🗃️
The document is made up of fields. Each field carries an identifying name. Typical fields are DATE, TO, SUBJECT, and BODY. Most fields are very simple, and some are complex, and the body field can be quite complex too 🫠 For example, DATE is a very constrained character string that specifies the date and time in ISO format. A more complex example is the TO field, which is a list of mailboxes, where a mailbox is itself a property list of address information items 📬 The BODY can be simply a character string, or a very structured collection of data representing information in different media.
The BODY may be structured to indicate a controlled presentation of multimedia information. Text, graphics, facsimile, and voice information all have a place in the body of a document ✨ The presentation of information units may be sequential, independent, or simultaneous 🎞️
1.5. Other Work 📚
This protocol benefited from earlier work on message protocols in the ARPA Network [2,3,4,5,6], as well as ideas from others about the design of computer message systems [7,8,9,10,11,12,13,14,15,16,17,18] 🙌
2. Specification 🧁
The structured format of a document is built on the basic data elements used in the Internet Message Protocol [1] 💖
2.1. Document 📄
The document is a property list of <name,value> pairs called fields. A few fields are specifically required, and many are optional. Some field values are simple and a few are quite complicated. In particular, the body value may be highly structured 🪆
Older message systems treated the document as divided into a header and a body, and used keywords to indicate specific header fields (for example, date, to, subject). Roughly speaking, this new structured format provides that same functionality by treating the name part of the <name,value> pair as a keyword. On top of that, this new format gets rid of the separate treatment of the body 🙈
It's impossible to foresee all the forms documents will take, so the standard for a document header has to be flexible 🌊 The approach here is to define a set of basic fields and allow adding whatever fields are necessary. Features added this way may not be understood by others, so be careful out there 👀
The minimum document is a property list of the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
SUBJECT subject string (text)
BODY a data structureA typical document is a property list containing the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
FROM list of mailboxes
TO list of mailboxes
CC list of mailboxes
SUBJECT subject string (text)
BODY a data structureAn elaborate document might contain the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
FROM list of mailboxes
TO list of mailboxes
CC list of mailboxes
BCC list of mailboxes
REPLY-TO list of mailboxes
SUBJECT subject string (text)
COMMENTS comment string (text)
MESSAGE-ID message identifier of this message (text)
IN-REPLY-TO message identifier of previous message (text)
REFERENCES message identifiers of other messages (text)
KEYWORDS key terms used in this message (text)
BODY a data structureOne of the key objects is the mailbox 🔑 It appears in the sender, from, to, cc, bcc, and reply-to fields. A mailbox is a property list of objects that combine to specify a destination recipient for a message. Most of the <name,value> pairs that make up a mailbox are identical to those used in the deliver command in the Internet Message Protocol [1]. A few extra <name,value> pairs are defined for use in a mailbox in the document context. In particular, there's a field for the real name of a person, as opposed to the "user name" that identifies a computer account 🧑💻
There's also a field to specify a distribution group name 👯 Group names indicate that a document is being sent to a group of recipients. This is basically an alternate form of mailbox, made up of the single <name,value> pair for the group name. There's no required relationship between a group name mailbox and other mailboxes in the same list 🫧
For example, all of the following situations are allowed:
- a mailbox list consisting of a single mailbox specifying a particular user,
- a mailbox list consisting of a single mailbox with a group name,
- a mailbox list consisting of a mailbox with a group name and a mailbox specifying a particular user, with either the user in or not in the group,
- a mailbox list consisting of a mailbox with a group name and a
several mailboxes specifying a particular users, with some users in the group and some not,
- a mailbox list consisting of several mailboxes specifying group names and a several mailboxes specifying a particular users, with some users in the groups and some not.
2.2. Message Objects
okay bestie, so the message docs use a whole set of little objects, like mailbox or date 💌 These objects are encoded in basic data elements ✨ Some are simple, like integers or character strings. Others are more complex, like lists or property lists 🎀 Here's the list of objects used in messages, in alphabetical order 💅
Account
The account information. Represented by a name element. 🗝️
Address
Address is meant to hold the minimum info needed to identify a user, and nothing extra (compare with mailbox) 🫶
An address is a property list with these <name,value> pairs:
name description
---- -----------
NET network name
HOST host name
USER user nameor:
name description
---- -----------
MPM mpm-identifier
USER user nameAnswer
A yes (true) or no (false) answer to a question. Represented by a boolean element. 🙋
BCC
A list of mailboxes. The addresses of those who receive "blind carbon copies" of the message. 🙈
Body
A data structure. This can be as simple as a character string (represented by a name or text element), or a complex structure of lists. It may be encrypted in part or in whole. Section 3.3 describes some possible structured bodies. 📦
C
A character. Represented by a name element. 🔤
CC
A list of mailboxes. When copies of a message are sent to others in addition to the addresses in the To object, those people get their addresses recorded here. 👀
City
A city. Represented by a name element. 🏙️
Comments
A comment string. Represented by a text element. 💬
Count
A count of items of some sort. Represented by an integer element. 🔢
Country
A country. Represented by a name element. 🌍
Date
The date and time are represented according to the International Standards Organization (ISO) recommendations [19,20,21]. Taken together, the ISO recommendations 2014, 3307, and 4031 give us this representation of the date and time: 🕰️
yyyy-mm-dd-hh:mm:ss,fff+hh:mmWhere yyyy is the four-digit year, mm is the two-digit month, dd is the two-digit day, hh is the two-digit hour in 24 hour time, mm is the two-digit minute, ss is the two-digit second, and fff is the decimal fraction of the second. Then we tack on the offset from Greenwich as plus or minus hh hours and mm minutes. ⏰
The time is local time, and the offset is the difference between local time and Coordinated Universal Time (UTC). To convert from local time to UTC, you algebraically subtract the offset from the local time. 🧮
For example, when the time in:
Los Angeles is 14:25:00-08:00
the UTC is 22:25:00or when the time in:
Paris is 11:43:00+01:00
the UTC is 10:43:00Device
A device name. Represented by a name element. 📱
Document
A property list of fields. 📄
Distribution Group
A distribution group is a property list which contains the following <name,value> pair:
name description
---- -----------
GROUP document distribution group nameThis construct is used so that a distribution group is a special case of a mailbox. 📨
Facsimile Structure
A facsimile data structure. Represented by a property list. 📠
File
A file name. Represented by a name element. 🗂️
Format
A format indicator. Represented by a name element. 🎞️
From
A list of mailboxes. The From is the name of the author of a document. ✍️
Graphics Structure
A graphics data structure. Represented by a property list. 🎨
Group
A document distribution group name. Represented by a name element. 👯
Host
A host name. Represented by a name element. 🖥️
Ident
The identifier of a person, usually their initials. Represented by a name element. 🪪
In-Reply-To
The message identifier of the previous message. Represented by a text element. ↩️
Internet Address
This identifies a host in the ARPA internetwork environment. The internet address is a 32 bit number. The higher order 8 bits identify the network, and the lower order 24 bits identify the host on that network [22]. For use in this format, the internet address is divided into eight bit fields, and the value of each field is represented in decimal digits. For example, the ARPANET address of ISIE is 167837748 and is represented as 10,1,0,52. This representation can also be extended to include an address within a host, such as the TCP port of an MPM, for example 10,1,0,52,0,45. 🌐
Keywords
The key terms used in this message. Represented by a text element. 🔑
Mailbox
This is the destination address of a user of the internetwork mail system. A mailbox contains information such as network, host, location, and local user identifier of the recipient of the message. The mailbox may contain information in addition to the minimum required for delivery. 📬
As an example, when someone sends a message to a person for the first time, they might include lots of items to help identify the correct recipient. However, once they get a reply to that message, the reply will contain an Address (as opposed to Mailbox) which can be used from then on. 💅
A mailbox is a property list. A mailbox might contain the following <name,value> pairs:
name description
---- -----------
MPM mpm-identifier
NET network name
HOST host name
PORT address of MPM within the host
USER user name (computer account name)
PERSON the real name of a person
GROUP document distribution group
ORG organization name
CITY city
STATE state
COUNTRY country
ZIP zip code
PHONE phone numberThe minimum mail box is an Address or a Distribution Group. 🎯
Message-ID
The message identifier of this message. This is not related to the MPM message identification. It is a UIP long term document identifier. Represented by a text element. 🆔
MPM-Identifier
The internetwork address of an MPM. This may be the ARPA Internet Address or an X.121 Public Data Network Address [23]. The mpm-identifier is a property list which has one <name,value> pair. This unusual structure is used so that it is easy to tell what type of address is being used. 🧩
Net
A network name. Represented by a name element. 🕸️
NLS Block
The information in an NLS node. Represented by a property list. 🧱
NLS Node
An NLS block and its substructure. Represented by a property list. 🌳
NLS Substructure
A list of NLS nodes. Represented by a list. 🌿
Org
An organization name. Represented by a name element. 🏢
Paragraph
A paragraph of text. Represented by a text element. 📝
Parcel
The basic unit of voice data. Represented by a bitstr element. 🎙️
Person
The real name of a person. Represented by a name element. 🧑
Password
A password. Represented by a name element. 🤫
Phone
A phone number. Represented by a name element. ☎️
Pointer
A pointer to information stored outside this data structure. It's a property list containing the information needed to locate the external data, the information needed to gain access to the external data, and the information needed to apply the correct interpretation to the external data. For example, this might include:
name description
---- -----------
NET network name
HOST host name
FILE file name
USER user name (computer account name)
PASSWORD password
ACCOUNT account
FORMAT format🧭
Port
The address of an MPM within the host. Represented by a name element. 🚪
Presentation Descriptor
A property list of <name,value> pairs, where the name is an order indicator, and the value is a presentation element. The order indicators are SEQUENTIAL, SIMULTANEOUS, and INDEPENDENT. 🎬
Presentation Element
A property list of media structures. 🖼️
Protocol
The name of the coding scheme used for a medium. Represented by a name element. 🛠️
References
The message identifiers of other messages. Represented by a list of text elements. 🔗
Reply-To
A list of mailboxes. Sometimes you'll want replies to a message sent to some address other than the From or the sender. In that case, the reply-to object can be used. 💌
R 450 Block
The unit of Rapicom 450 data (585 bits). Represented by a bitstr element. 📟
Sender
A mailbox. The sender contains the address of the individual who sent the message. In some cases this is not the same as the author of the message. In that situation, the author should be specified in the From object. 🫵
SID
An NLS statement identifier. Represented by an integer element. 🪄
State
A state name. Represented by a name element. 🗺️
Subject
The subject of the message. Represented by a text element. 🎀
Text Structure
A text data structure. Represented by a property list. 📚
To
A list of mailboxes. To identifies the addressees of the message. 🎯
User
A user name (computer account name). Represented by a name element. 👩💻
Version
A version number. Represented by an index element. 🔖
Vocoder
A vocoder name. Represented by a name element. 🎤
Voice Structure
A voice data structure. Represented by a property list. 🔊
X121 Address
This identifies a host in the Public Data Network environment. When used as part of an identifier, it identifies the originating host of a message. The X121 address is a sequence of up to 14 digits [23]. For use in this format, the X121 address is represented in decimal digits. 🛰️
ZIP
A zip code. Represented by a name element. 📮
2.3. Body Structures
2.3.1. Simple Elements
The body could just be a single data element. For example, a single text element can hold a lengthy character string. 📖
<body> := TEXT
or
text:"this is the actual text of the body"2.3.2. Structured Text
The body could be thought of as paragraphs, where each paragraph is represented by a text element. The paragraphs are then the elements of a list. 🧃
<body> := LIST (<paragraph>, <paragraph>, ...)
<paragraph> := TEXT
or
list:(text:"paragraph one", text:"paragraph two", ...)2.3.3. NLS File Example
It is possible to represent the data from NLS files in this format. NLS is a large, multipurpose system which operates on structured data files. The files are tree structured, and there is data associated with each node of the tree. Each node also has several fields attached to it. 🌲✨
An NLS file is:
Okay so this is where the NLS structures get really nesty 🧚 Here's the file-level property list first, then the substructures, nodes, blocks, and data inside them:
proplist( file
name:"FILENAME", name:<file> name of file
name:"CREATION-DATE", name:<date> creation date and time
name:"VERSION", index:<version> file version number
name:"SID-COUNT", integer<count> current SID count
name:"LAST-WRITER", name:<ident> last writer of file
name:"OWNER", name:<ident> owner of file
name:"LAST-WRITE-TIME", name:<date> last write date and time
name:"LEFT-NAME-DELIM-DEFAULT", name:<c> default name
name:"RIGHT-NAME-DELIM-DEFAULT", name:<c> delimiters
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlistAn NLS substructure is a list like this, where each entry is an NLS node 💅
list:( substructure
<nls-node> node is defined below
.
.
.
)endlistAn NLS node is a property list holding a block and a substructure 🌸
proplist:( node
name:"BLOCK", <nls-block> block defined below
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlistAn NLS block is where the actual statement info lives: delimiters, SID, creator, creation time, and data 🎀
proplist:( block
name:"LEFT-NAME-DELIM", name:<c> left name delimiter
name:"RIGHT-NAME-DELIM", name:<c> right name delimiter
name:"SID", integer:<sid> SID number
name:"CREATOR", name:<ident> statement creator
name:"CREATION-TIME", name:<date> creation date and time
name:"DATA", <data> data defined below
)endlistNLS data is a property list where each entry is named by a data name, and the type of the value depends on that name ✨
proplist:( data
name:"<a data name>", <type depends on data name>
. .
. .
. .
)endlistFor text, the data is just one TEXT entry holding the statement's text 🦋
proplist:( data
name:"TEXT", text:"text of statement" text
)endlist2.3.4. Multimedia Structures ✨
Picture this: graphics showing up on screen while someone talks over them, kinda like a seminar with slides 🎀 A slide and its description are tied together, and the timing between them is honestly central to understanding the whole thing. So that synchronization should be captured right inside the document structure. Obsessed with this idea tbh 💜
There are three fundamentally different types of time-ordered control that the document structure needs:
- Simultaneous
- Sequential
- Independent
Simultaneous data is meant for synchronous presentation, which means it gets presented in parallel 🔥
Sequential data items get presented one at a time, in the order they're listed. It's strictly left to right, no skipping ahead 💅
Independent data can be presented in any time order. It isn't ordered in any manner at all 🦋
The data gets broken into small information units called presentation elements, or PEs 🌈 PEs can be combined into structures that control the presentation order. A PE is a property list of elements that each represent information in some medium. For example:
<pe> := proplist(
name:"VOICE", <voice-structure>,
name:"GRAPHICS", <graphics-structure>
)endlistPEs get combined into larger controlled presentations by presentation-descriptors, or PDs. A PD is a property list that specifies the type of time ordering for the PEs in its list 🍓
<pd> := <<seq>> | <<sim>> | <<ind>>
<<seq>> := name:"SEQUENTIAL", <pe>
<<sim>> := name:"SIMULTANEOUS", <pe>
<<ind>> := name:"INDEPENDENT", <pe>A PE is a property list of the media <name,value> pairs, or PDs. Here's what each one can look like:
<pe> := <<text>> | <<voice>> | <<facsimile>>
| <<graphics>> | <pd>
<<text>> := name:"TEXT", <text structure>
<<voice>> := name:"VOICE", <voice structure>
<<facsimile>> := name:"FACSIMILE", <facsimile structure>
<<graphics>> := name:"GRAPHICS", <graphics structure>If a PE has more than one <name,value> pair, the media get presented on different output devices, in the order specified by the PE's parent PD. The order of appearance inside the proplist only matters when the parent PD specified sequential ordering 👑
Multimedia messages that use this scheme are shown off with a few simple examples. They cover a basic text document and the different ordering options, and the last one hints at some more exotic uses 🧚
Plain Text Message
A simple text body could be represented in a single text data structure. To give the simplest example of a structured body, we show a simple text body represented in the multimedia structure 📝
<body> := <pd>
<pd> := <<seq>>
<<seq>> := name:"SEQUENTIAL", <pe>
<pe> := name:"TEXT", <text structure>
or
proplist: (name:"SEQUENTIAL",
proplist:(
name:"TEXT", <text structure>
)endlist
)endlistSimultaneous Ordering
This ordering option is used to indicate when separate streams are to be presented in parallel. For example, let's say GRAPHICS and VOICE data were to be presented simultaneously 🎶
<body> := <pd>
<pd> := <<sim>>
<<sim>> := name:"SIMULTANEOUS", <pe>
<pe> := name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
or
proplist:(
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist
)endlistSequential Ordering
This option is used to indicate sequential time ordering. The media in the sub-tree below this PD are not separate streams. Using the same example again, let's say GRAPHICS and VOICE data were to be presented sequentially 🫶
<body> := <pd>
<pd> := <<seq>>
<<seq>> := name:"SEQUENTIAL", <pe>
<pe> := name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
or
proplist:(
name:"SEQUENTIAL",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist
)endlistIndependent Ordering
Some output devices are very slow compared to others 🙈 Facsimile is the classic example. Most facsimile devices are slow, and a detailed picture sent at 9600 baud takes minutes to print. It's really inconvenient for the user to wait around on that when the voice or text that comes with it is short 😭
Say the document is a facsimile image plus the text "Hello Frank, here's a copy of that picture you requested." The user doesn't need to wait for the picture. If the facsimile machine is spooled, they can just pick the picture up later. In a sense, the picture is time independent of the text 💖
<body> := <pd>
<pd> := <<ind>>
<<ind>> := name:"INDEPENDENT", <pe>
<pe> := name:"FACSIMILE", <facsimile structure>
name:"TEXT", <text structure>
or
proplist:(
name:"INDEPENDENT",
proplist:(
name:"FACSIMILE", <facsimile structure>
name:"TEXT", <text structure>
)endlist
)endlistA Stream Example
By using the structure together with the sequential ordering option, it's possible to start a stream. The stream proceeds at its own pace until it's concluded 🌊
<body> := <pd>
<pd> := <<seq>>
<<seq>> := name:"SEQUENTIAL", <pe>
<pe> := <pd>
<pd> := <<sim>>
<<sim>> := name:"SIMULTANEOUS", <pe>
<pe> := name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
or
proplist:(
name:"SEQUENTIAL",
proplist:(
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist,
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist,
.
.
.
)endlist
)endlistSuch a document structure suggests a slide presentation 🎞️✨
Multiple Active Stream Example
This one is exotic, but it shows what's possible 🤯 By using the structure together with the simultaneous ordering, it's possible to start two or more separate streams in parallel. Each stream proceeds at its own pace until all of them are concluded 🌈
<body> := <pd>
<pd> := name:"SIMULTANEOUS", <pe>
<pe> = <pd>
<pd> := name:"SEQUENTIAL", <pe>
<pe> = <pd>
<pd> := name:"SIMULTANEOUS", <pe>
<pe> := name:"VOICE",
<voice structure>
name:"GRAPHICS",
<graphics structure>
or
proplist:(
name:"SIMULTANEOUS",
proplist:(
name:"SEQUENTIAL",
proplist:(
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist,
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist,
.
.
.
)endlist
name:"SEQUENTIAL",
proplist:(
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist,
.
.
.
)endlist
)endlist
)endlist2.3.5. The Media
So far there's no explicit description for the media classes that fit into a PE 🫠 It isn't known which media types will be supported by the various document stations in the future. The ones that already have partial support are:
- TEXT
- VOICE
- FACSIMILE
- GRAPHICS
Standard formats for data in each of these media must be defined 📋
2.3.6. TEXT
Text data may be structured according to a variety of protocols, which are yet to be defined 🌷 The top level of the data structure is a property list that identifies the protocol and the version of that protocol 💜
name:"TEXT", proplist:(
name:"PROTOCOL", <protocol>,
name:"VERSION", <version>,
name:"DATA", <data>
)endlistokay bestie, the first protocol is PARAGRAPH 💖 and the data is just a list of paragraphs, where every paragraph is a text element ✨
name:"DATA", list:(
text: <paragraph>
text: <paragraph>
.
.
.
)endlist2.3.7. VOICE 🎙️
okay so people have done a lot of research on sending voice data over the ARPANET 😭 which is why the Network Voice Protocol (NVP) is the base for the voice data standard [24] 🫶
Voice data is a property list that tells you which vocoder is being used, which transmission protocol, and the parcel data. The parcel data form depends on the protocol and gets grouped into lists 💅
name:"VOICE", proplist:(
name:"VOCODER", <vocoder>,
name:"PROTOCOL", <protocol>,
name:"VERSION", <version>,
name:"DATA", <data>
)endlistThe NVP protocol has a bunch of parameters, and the version number picks out a specific set of them. Those are what the vocoder hardware and software use to set up timing and decide the type of coding ⏱️ It's not expected that the version number will change within a document 🌸
NVP itself can negotiate these parameters so both ends of a network speech connection 'understand' each other 🤝 But a document system can't do interactive negotiation, so negotiation capabilities got left out 🙈 As different hardware shows up, new versions may be defined ✨
For the NVP protocol, the data list looks like this:
name:"DATA", list:(
bitstr: <parcel>
bitstr: <parcel>
.
.
.
)endlistThe items in the list are parcels 📦 Each parcel is a bit string data element, and its contents and length are predefined by the version number. You can get the number of parcels in a parcel group from the item count in the enclosing list header 🧮
2.3.8. FACSIMILE 📠
There are a bunch of facsimile devices out there 📠 CCITT [25] is setting up standards, but a lot of the devices available today are incompatible because they use proprietary compression algorithms 😤 The fax data description is going to leave room for several protocols, so it's flexible 🦋
name:"FACSIMILE", proplist:(
name:"DEVICE", <device>,
name:"PROTOCOL", <protocol>,
name:"DATA", <data>
)endlistNot many facsimile devices are hooked up to computers though 🙃 The experiments on the ARPANET all use the RAPICOM 450, so the first facsimile standard format is based on the data structure used for that machine [26] 🖨️ So for device RAPICOM450 and protocol BLOCK, the data looks like this:
name:"DATA", list:(
bitstr:<r450-block>,
bitstr:<r450-block>,
.
.
.
)endlistAnd an r450-block is a 585 bit unit 🔢 that's it, that's the tea 🍵
2.3.9. GRAPHICS 🎨
Graphics is giving the same energy as facsimile 👯 Devices on the market have all kinds of user interfaces and options, so a similar structure is defined ✨
name:"GRAPHICS", proplist:(
name:"DEVICE", <device>,
name:"PROTOCOL", <protocol>,
name:"DATA", <data>
)endlistThere are a few candidate protocols for describing graphics data in documents 🌈 One is the Network Graphics Protocol [27], another is the Graphics Language [28,29], and the third is the SIGGRAPH Core System [30] 💜
3. EXAMPLES & SCENARIOS 🎬
Example 1: Text Example
Okay, picture this: we want to send the following message 💌
Date: 1979-03-29-11:46-08:00
From: Jon Postel <Postel@ISIF>
Subject: Meeting Thursday
To: Danny Cohen <Cohen@ISIB>
CC: Linda
Danny:
Please mark your calendar for our meeting Thursday at 3 pm.
--jon.It gets encoded in the structured format 🧚 The steps below show the top-down generation of this message, step by step 🪜 The identification and command portions of the messages won't be expanded here (see [1]) 🙈
1. message
2. (identification, command, document)
3. (ID:<<identification>>,
CMD:<<command>>,
DOC:( date, from, subject, to, cc, body))
4. (ID:<<identification>>,
CMD:<<command>>,
DOC:(DATE:date,
FROM:from
SUBJECT:subject,
TO:to,
CC:cc,
BODY:body))
5. (ID:<<identification>>,
CMD:<<command>>,
DOC:(DATE: 1979-03-29-11:46-08:00,
FROM: (NET:ARPANET,HOST:ISIF,USER:Postel,PERSON:Jon Postel),
SUBJECT: Meeting Thursday,
TO: (NET:ARPANET,HOST:ISIB,USER:Cohen,PERSON:Danny Cohen),
CC: (NET:ARPANET,HOST:ISIF,USER:Linda),
BODY:
Danny:
Please mark your calendar for our meeting
Thursday at 3 pm.
--jon.))
6. PROPLIST:
(ID:<<identification>>,
CMD:<<command>>,
DOC:
PROPLIST:(
DATE: 1979-03-29-11:46-08:00,
FROM:
LIST:(
PROPLIST:(
NET:ARPANET,
HOST:ISIF,
USER:Postel,
PERSON:Jon Postel,
)ENDLIST,
)ENDLIST,
SUBJECT: Meeting Thursday,
TO:
LIST:(
PROPLIST:(
NET:ARPANET,
HOST:ISIB,
USER:Cohen,
PERSON:Danny Cohen,
)ENDLIST,
)ENDLIST,
CC:
LIST:(
PROPLIST:(
NET:ARPANET,
HOST:ISIF,
USER:Linda,
)ENDLIST,
)ENDLIST,
BODY:
Danny:
Please mark your calendar for our
meeting Thursday at 3 pm.
--jon.
)ENDLIST
)ENDLIST
7. proplist:(
name:"ID", <<identification>>,
name:"CMD", <<command>>,
name:"DOC",
proplist:(
name:"DATE", name:"1979-03-29-11:46-08:00",
name:"FROM",
list:(
proplist:(
name:"NET", name:"ARPANET",
name:"HOST", name:"ISIF",
name:"USER", name:"Postel",
name:"PERSON", name:"Jon Postel",
)endlist,
)endlist,
name:"SUBJECT", text:"Meeting Thursday",
name:"TO",
list:(
proplist:(
name:"NET", name:"ARPANET",
name:"HOST", name:"ISIB",
name:"USER", name:"Cohen",
name:"PERSON", name:"Danny Cohen",
)endlist,
)endlist,
name:"CC",
list:(
proplist:(
name:"NET", name:"ARPANET",
name:"HOST", name:"ISIF",
name:"USER", name:"Linda",
)endlist,
)endlist,
name:"BODY",
text:"Danny:
Please mark your calendar for our
meeting Thursday at 3 pm.
--jon."
)endlist
)endlistExample 2: Multimedia Example 🎞️
this one is the multimedia era 😭✨
proplist:(
name:"ID", <<identification>>,
name:"CMD", <<command>>,
name:"DOC",
proplist:(
name:"DATE", name:"1980-08-06-11:46-08:00",
name:"FROM",
list:(
proplist:(
name:"NET", name:"ARPANET",
name:"HOST", name:"ISIF",
name:"USER", name:"Postel",
name:"PERSON", name:"Jon Postel",
)endlist,
)endlist,
name:"SUBJECT", text:"Multimedia Test Message",
name:"TO",
list:(
proplist:(
name:"GROUP", name:"Multimedia Experiment List",
)endlist,
)endlist,
name:"CC",
list:(
proplist:(
name:"NET", name:"ARPANET",
name:"HOST", name:"ISIF",
name:"USER", name:"Linda",
)endlist,
)endlist,
name:"BODY",
proplist:(
name:"SEQUENTIAL",
proplist:(
name:"TEXT",
proplist:(
name:"PROTOCOL", name:"PARAGRAPH",
name:"VERSION", index:"1",
name:"DATA",
list:(
text:"This is a test of multimedia mail."
text:"I hope you like it."
)endlist
)endlist
name:"SIMULTANEOUS",
proplist:(
name:"VOICE",
proplist:(
name:"VOCODER", name:<vocoder>,
name:"PROTOCOL", name:"NVP",
name:"VERSION", index:"1",
name:"DATA",
list:(
bitstr:<parcel>
bitstr:<parcel>
)endlist
)endlist
name:"GRAPHICS",
proplist:(
name:"DEVICE", name:<device>,
name:"PROTOCOL", name:<protocol>,
name:"VERSION", index:<version>,
name:"DATA",<data>
)endlist
)endlist
)endlist
name:"SEQUENTIAL",
proplist:(
name:"TEXT,
proplist:(
name:"PROTOCOL", name:"PARAGRAPH",
name:"VERSION", index:"1",
name:"DATA",
list:(
text:"That was supposed to be some voice
and graphics in parallel."
text:"--jon."
)endlist
)endlist
)endlist
)endlist
)endlist
)endlistREFERENCES 📚
okay bestie, here's the whole reading list 🧚 every single source the spec leans on, so you can go deep if you want 💅
- [1] Postel, J., "Internet Message Protocol," RFC 759, 113, USC/Information Sciences Institute, August 1980.
- [2] Bhushan, A., K. Pogran, R. Tomlinson, and J. White, "Standardizing Network Mail Headers," RFC 561, NIC 18516, September 1973.
- [3] Myer, T., and D. Henderson, "Message Transmission Protocol," RFC 680, NIC 32116, 30 April 1975.
- [4] Crocker, D., J. Vittal, K. Pogran, and D. Henderson, "Standard for the Format of ARPA Network Text Messages," RFC 733, NIC 41952, 21 November 1977.
- [5] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192, February 1979.
- [6] Braaten, O., "Introduction to a Mail Protocol," Norwegian Computing Center, INWG 180, August 1978.
- [7] Crocker, D., E. Szurkowski, and D. Farber, "An Internetwork Memo Distribution Capability - MMDF," Sixth Data Communications Symposium, ACM/IEEE, November 1979.
- [8] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed Specification of an Inter-site Message Protocol," 8 July 1975.
- [9] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW Working Note 24, Bolt Beranek and Newman, October 1978.
- [10] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, SRI International, 13 June 1973.
- [11] White, J., "Description of a Multi-Host Journal," NIC 23144, SRI International, 30 May 1974.
- [12] White, J., "Journal Subscription Service," NIC 23143, SRI International, 28 May 1974.
- [13] Levin, R., and M. Schroeder, "Transport of Electronic Messages Through a Network," Teleinformatics 79, Boutmy & Danthine (eds.) North Holland Publishing Co., 1979.
- [14] Earnest, L., and J. McCarthy, "DIALNET: A Computer Communications Study," Computer Science Department, Stanford University, August 1978.
- [15] Crispin M., "DIALNET: A Telephone Network Data Communications Protocol," DECUS Proceedings, Fall 1979.
- [16] Caulkins, D., "The Personal Computer Network (PCNET) Project: A Status Report," Dr. Dobbs Journal of Computer Calisthenics and Orthodontia, v.5, n.6, June 1980.
- [17] Postel, J., "NSW Transaction Protocol (NSWTP)," USC/Information Sciences Institute, IEN 38, May 1978.
- [18] Haverty, J., "MSDTP -- Message Services Data Transmission Protocol," RFC 713, NIC 34739, April 1976.
- [19] ISO-2014, "Writing of calendar dates in all-numeric form," Recommendation 2014, International Organization for Standardization, 1975.
- [20] ISO-3307, "Information Interchange -- Representations of time of the day," Recommendation 3307, International Organization for Standardization, 1975.
- [21] ISO-4031, "Information Interchange -- Representation of local time differentials," Recommendation 4031, International Organization for Standardization, 1978.
- [22] Postel, J., "DOD Standard Internet Protocol," USC/Information Sciences Institute, IEN 128, NTIS number AD A079730, January 1980.
- [23] CCITT-X.121, "International Numbering Plan for Public Data Networks," Recommendation X.121, CCITT, Geneva, 1978.
- [24] Cohen, D., "Specifications for the Network Voice Protocol (NVP)," NIC 42444, RFC 741, NSC 68, RR-75-39, USC/Information Sciences Institute, January 1976.
- [25] CCITT-T.30, "Procedures for Document Facsimile Transmission in the General Switched Telephone Network," Recommendation T.30, Orange Book, V. 7, The International Telephone and Telegraph Consulative Committee, International Telecommunication Union, Geneva, 1977.
- [26] Treadwell, S., "FAX File Format," ARPANET Message, 14 November 1979.
- [27] Sproull, R., and E. Thomas, "A Network Graphics Protocol," NIC 24308, Xerox Palo Alto Research Center, August 1974.
- [28] Bisbey, R., and D. Hollingworth, "A Distributable, Display-Device-Independent Vector Graphics System for Command and Control," RR-80-87, USC/Information Sciences Institute, July 1980.
- [29] Bisbey, R., D. Hollingworth, and B. Britt, "Graphics Language," TM-80-18, USC/Information Sciences Institute, July 1980.
- [30] Graphics Standard Planning Committee, "Core System," Computer Graphics, V. 13, N. 3, SIGGRAPH, ACM, August 1979.
📦 where this page comes from
- ietf: rfc767 1980-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms