RFC767 日本語訳
0767 Structured format for transmission of multi-media documents. J.Postel. August 1980. (Format: TXT=59971 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC:767
RFC: 767
A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS
マルチメディアドキュメントの伝達のための構造化された形式
Jonathan B. Postel
ジョナサン・B.ポステル
August 1980
1980年8月
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
南カリフォルニア4676海軍本部Wayマリナデルレイ、カリフォルニア 90291人の情報Sciences Institute大学
(213) 822-1511
(213) 822-1511
< INC-PROJECT, MMMSFS.NLS.21, >, 5-Sep-80 20:19 JBP ;;;;
<INC-プロジェクト、MMMSFS.NLS.21、>、1980年9月5日20時19分JBP。
Postel
ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
TABLE OF CONTENTS
目次
PREFACE ........................................................ iii
PREFACE… iii
1. INTRODUCTION ..................................................... 1
1. 序論… 1
1.1. Motivation ................................................... 1 1.2. Scope ........................................................ 1 1.3. Terminology .................................................. 1 1.4. Document Description ......................................... 2 1.5. Other Work ................................................... 2
1.1. 動機… 1 1.2. 範囲… 1 1.3. 用語… 1 1.4. 記述を記録してください… 2 1.5. 他の仕事… 2
2. SPECIFICATION .................................................... 3
2. 仕様… 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
2.1. 記録します。 3 2.2. メッセージオブジェクト… 5 2.3. ボディー構造… 13 2.3.1. 純真なElements… 13 2.3.2. テキストを構造化します… 13 2.3.3. NLSは例をファイルします… 13 2.3.4. マルチメディア構造… 15 2.3.5. メディア… 21 2.3.6. テキスト… 22 2.3.7. 声… 22 2.3.8. 電送します。 23 2.3.9. グラフィックス… 24
3. EXAMPLES & SCENARIOS ............................................ 25
3. 例とシナリオ… 25
Example 1: Text Example .......................................... 25 Example 2: Multimedia Example .................................... 28
例1: テキストの例… 25 例2: マルチメディアの例… 28
REFERENCES .......................................................... 31
参照… 31
Postel [Page i]
ポステル[ページi]
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
[Page ii] Postel
[ページii] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
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 this is listed in the reference section. This specification was shaped by many discussions with members of the ARPA research community, and others interested in the development of computer aided message systems. This document was prepared as part of the ARPA sponsored Internetwork Concepts Research Project at ISI.
これは、この書式仕様の初版であり、コメント、アドバイス、および提案のために要求として扱われるべきです。 コンピュータの支援されたメッセージシステムの上で大きな先の仕事をしました、そして、参照部でこの或るものを記載します。 この仕様はARPA研究団体のメンバーとの多くの議論で形成されました、そして、コンピュータの開発に興味を持っている他のものはメッセージシステムを支援しました。ARPAの一部がISIでInternetwork Concepts Research Projectを後援したとき、このドキュメントは準備されました。
Jon Postel
ジョン・ポステル
Postel [Page iii]
ポステル[ページiii]
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
Postel [Page iv]
ポステル[ページiv]
RFC: 767 J. Postel
USC-ISI
August 1980
RFC: 767 J.ポステルUSC-ISI1980年8月
A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS
マルチメディアドキュメントの伝達のための構造化された形式
1. INTRODUCTION
1. 序論
This document describes a format for transmitting structured data representations of multimedia documents. This format is intended to be used with the Internet Message Protocol in an internetwork message delivery system. That system is designed to transmit messages between processes in host computers called Message Processing Modules (MPMs). MPMs are located in several networks and together constitute an internetwork message delivery system. The Internet Message Protocol defines a message as being composed of an Identification, a Command, and a Document. This report is intended to define the format of such Documents. The reader is assumed to be familiar with the Internet Message Protocol [1].
このドキュメントは、マルチメディアドキュメントの構造化されたデータ表現を伝えるために形式について説明します。 インターネットワークメッセージ配送システムのインターネットMessageプロトコルと共にこの形式が使用されることを意図します。 そのシステムは、Message Processing Modules(MPMs)と呼ばれるホストコンピュータのプロセスの間にメッセージを送るように設計されています。 MPMsはいくつかのネットワークに一緒に見つけられています。インターネットワークメッセージ配送システムを構成してください。 インターネットMessageプロトコルはIdentification、Command、およびDocumentで構成されるとメッセージを定義します。 このレポートがそのようなDocumentsの書式を定義することを意図します。 読者がインターネットMessageプロトコル[1]によく知られさせると思われます。
1.1. Motivation
1.1. 動機
Computer applications are being implemented which interact with users in a variety of media (text, graphics, facsimile, speech). As computer devices become available to process multimedia information it becomes desirable to use computers to exchange multimedia information between programs and users via various mechanisms including computer mail.
さまざまなメディア(テキスト、グラフィックス、ファクシミリ、スピーチ)でユーザと対話するコンピュータアプリケーションが実装されています。 コンピュータデバイスがマルチメディア情報を処理するために利用可能になるのに従って、コンピュータメールを含んでいて、プログラムとユーザの間で様々なメカニズムでマルチメディア情報を交換するのにコンピュータを使用するのは望ましくなります。
1.2. Scope
1.2. 範囲
This format is intended to be used for the transmission of multimedia documents in the internetwork message delivery system, but it is thought that it has a wider applicability.
インターネットワークメッセージ配送システムにおける、マルチメディアドキュメントの伝達にこの形式が使用されることを意図しますが、それには、より広い適用性があると思われます。
1.3. Terminology
1.3. 用語
The messages are routed by a process called the Message Processing Module or MPM. Messages are created and consumed by User Interface Programs (UIPs) in conjunction with users.
メッセージはMessage Processing ModuleかMPMと呼ばれるプロセスによって発送されます。 メッセージは、ユーザに関連してUser Interface Programs(UIPs)によって作成されて、消費されます。
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 necessary information for delivery), and document. The document is a data structure.
MPMsの間に移された原単位はメッセージと呼ばれます。 メッセージはトランザクション識別子(唯一メッセージを特定する)、コマンド(配送のための必要事項を含む)、およびドキュメントで作られます。 ドキュメントはデータ構造です。
For a personal letter the document body corresponds to the contents of
文書本体がコンテンツに対応する親書のために
Postel [Page 1]
ポステル[1ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Introduction
1980年8月に、マルチメディアの送信のための構造化された形式は序論を記録します。
the letter; the document header corresponds to the date line, greeting, and signature.
手紙。 ドキュメントヘッダーは日付変更線、挨拶、および署名に文通しています。
For an inter-office memo the document body corresponds to the text; the document header corresponds to the header of the memo.
相互事務連絡用メモに関しては、文書本体はテキストに対応します。 ドキュメントヘッダーはメモのヘッダーに文通しています。
The commands correspond to the information used by the Post Office or the mail room to route the letter or memo. Some of the information in the command is supplied by the UIP.
コマンドはポストオフィスによって使用された情報か手紙かメモを発送するメール部屋に対応しています。 コマンドにおける何らかの情報がUIPによって提供されます。
1.4. Document Description
1.4. ドキュメント記述
The document is composed of fields. Each field will carry an identifying name. Typical fields are DATE, TO, SUBJECT, and BODY. Most of the fields will be very simple, some will be complex. The body field may be quite complex. For example, the DATE is a very constrained character string specifying 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 may be simply a character string, or a very structured collection of data representing information in different media.
ドキュメントは分野で構成されます。 各分野は特定名を運ぶでしょう。 典型的な分野は、DATEと、TOと、SUBJECTと、BODYです。 分野の大部分が非常に簡単になる、或るものは複雑になるでしょう。 ボディー分野はかなり複雑であるかもしれません。 例えば、DATEはISO形式で日時を指定する非常に制約つきな文字列です。 より複雑な例はメールボックスのリストであるTO分野です。そこでは、メールボックスがそれ自体でアドレス情報項目の特性のリストです。BODYは単に文字列、または異なったメディアによる情報を表すデータの非常に構造化された収集であるかもしれません。
The BODY may be structured to indicate a controlled presentation of multimedia information. There is provision for the inclusion of text, graphics, facsimile, and voice information in the body of documents. The presentation of information units may sequential, independent, or simultaneous.
BODYは、マルチメディア情報の制御プレゼンテーションを示すために構造化されるかもしれません。 テキスト、グラフィックス、ファクシミリ、および声の情報の包含への支給がドキュメントのボディーにあります。 情報ユニットのプレゼンテーションは同時であるかもしれません。連続する、独立する、または同時です。
1.5. Other Work
1.5. 他の仕事
This protocol the benefited from the earlier work on message protocols in the ARPA Network [2,3,4,5,6], and the ideas of others about the design of computer message systems [7,8,9,10,11,12,13,14,15,16,17,18].
これはコンピュータメッセージシステム[7、8、9、10、11、12、13、14、15、16、17、18]の設計に関してアーパネット[2、3、4、5、6]のメッセージプロトコル、および他のものの考えに対する以前の仕事からのためになることについて議定書の中で述べます。
[Page 2] Postel
[2ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
2. SPECIFICATION
2. 仕様
The structured format of a document is built on the basic data elements used in the Internet Message Protocol [1].
ドキュメントの構造化された形式はインターネットMessageプロトコル[1]に使用される基礎データ要素の上で築き上げられます。
2.1. Document
2.1. ドキュメント
The document is a property list of <name,value> pairs called fields. A few fields are specifically required and many are optional. Some of the field values are simple and a few are quite complicated. In particular the body value may be highly structured.
分野と呼ばれる>組は、ドキュメントが<名の特性のリストであることを評価します。 いくつかの分野が明確に必要です、そして、多くが任意です。 分野値のいくつかが簡単です、そして、いくつかはかなり複雑です。 特に、ボディー値は非常に構造化されるかもしれません。
Older message systems have considered the document to be divided into a header and a body, and have used keywords to indicate specific header fields (e.g., date, to, subject). Roughly speaking, this functionality is provided in this new structured format by considering the name part of the <name,value> pair to be a keyword. In addition, this new structured format eliminates the separate treatment of the body.
より古いメッセージシステムがドキュメントがヘッダーとボディーに分割されると考えて、特定のヘッダーフィールドを示すのにキーワードを使用した、(例えば、デートしてください、対象) 大まかに言えば、名前が<名(キーワードである値の>組)の一部であると考えることによって、この新しい構造化された形式にこの機能性を提供します。 さらに、この新しい構造化された形式はボディーの別々の処理を排除します。
It is impossible to foresee the many forms documents will take so the standard for a document header must be flexible. The approach here is to define a set of basic fields and allow addition of whatever fields are necessary. Features added in this fashion may not be understood by others.
ドキュメントヘッダーの規格がフレキシブルであるに違いないことで、ドキュメントが取る多くの形について見通すのは不可能です。 ここでのアプローチは、1セットの基礎体を定義して、いかなる必要な分野の追加も許容することです。 こんなやり方で加えられた特徴は他のものに解釈されないかもしれません。
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 structure
名前値---- ----- DATEはメールボックスのSUBJECTの対象のストリング(テキスト)BODY aデータ構造とストリング(名前)SENDERをデートします。
A 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 structure
名前値---- ----- メールボックスTOのメールボックスFROMリストが記載するメールボックスのDATE日付ストリング(名前)SENDERはメールボックスSUBJECT対象のストリング(テキスト)BODYのリストにデータ構造をCCします。
Postel [Page 3]
ポステル[3ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
An 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 structure
名前値---- ----- DATEはメールボックスCCのメールボックスTOリストのメールボックスFROMリストが記載する他のメッセージ(テキスト)のKEYWORDSの主要な用語に関する前のメッセージ(テキスト)REFERENCESメッセージ識別子に関するこのメッセージ(テキスト)IN-REPLY-TOメッセージ識別子に関するメールボックスSUBJECT対象のストリング(テキスト)COMMENTSコメントストリング(テキスト)MESSAGE-IDメッセージ識別子のメールボックスREPLY-TOリストのBCCリストがこのメッセージ(テキスト)BODYで使用したメールボックスのストリング(名前)SENDERをデータ構造とデートします。
One of the key objects is the mailbox. It appears in the sender, from, to, cc, bcc, and reply-to fields. The 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 additional <name,value> pairs are defined for use in a mailbox in the document context. In particular, there is a field for the real name of a person in contrast to the "user name" which identifies a computer account.
主要なオブジェクトの1つはメールボックスです。 それが送付者に現れる、cc、分野にbccして、答えてください。 メールボックスは結合する、目的地受取人をメッセージに指定するオブジェクトの特性のリストです。 <名の大部分、メールボックスを作る値の>組はインターネットMessageプロトコル[1]に配送コマンドに使用されるものと同じです。 いくつかの追加<名であり、値の>組はドキュメント文脈のメールボックスにおける使用のために定義されます。 特に、人の本名のための分野はコンピュータアカウントを特定する「ユーザ名」と対照的になっています。
In addition there is a field to specify a distribution group name. Such group names are used to indicate that a document is being sent to a group of recipients. This essentially presents an alternate form for a mailbox which consists of the single <name,value> pair for the group name. There is 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
. グループ名とaでメールボックスから成るメールボックスリスト
[Page 4] Postel
[4ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
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
2.2. メッセージオブジェクト
In the documents of messages, we use a set of objects such as mailbox or date. These objects are encoded in basic data elements. Some objects are simple things like integers or character strings, other objects are more complex things like lists or property lists. The following is a list of the objects used in messages. The object descriptions are in alphabetical order.
メッセージのドキュメントでは、私たちは、1セットのメールボックスなどのオブジェクトを使用するか、またはデートします。 これらのオブジェクトは基礎データ要素でコード化されます。 いくつかのオブジェクトが整数や文字列のように簡単なものである、他のオブジェクトはリストや特性のリストのように、より複雑なものです。 ↓これはメッセージで使用されるオブジェクトのリストです。 オブジェクト記述がアルファベット順にあります。
Account
アカウント
The account information. Represented by a name element.
会計情報。 名前要素で、表されます。
Address
アドレス
Address is intended to contain the minimum information necessary to
identify a user, and no more (compare with mailbox).
アドレスがユーザ、およびノー、をさらに特定するのに必要な最小の情報を含むことを意図します(メールボックスと比較してください)。
An address is a property list which contains the following
<name,value> pairs:
>組は、アドレスが以下の<名を含む特性のリストであることを評価します:
name description
---- -----------
NET network name
HOST host name
USER user name
名前記述---- ----------- NETネットワーク名HOSTホスト名USERユーザ名
or:
または、:
name description
---- -----------
MPM mpm-identifier
USER user name
名前記述---- ----------- MPM mpm識別子USERユーザ名
Answer
答え
A yes (true) or no (false) answer to a question. Represented by a
boolean element.
はい(本当の)にもかかわらず、(誤っている)の質問への答がありません。 論理演算子要素で、表されます。
Postel [Page 5]
ポステル[5ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
BCC
BCC
A list of mailboxes. The addresses of those who receive "blind
carbon copies" of the message.
A list of mailboxes. The addresses of those who receive "blind carbon copies" of the message.
Body
Body
A data structure. This may be as simple as a character string
(represented by a name or text element), or complex structure of
lists. It may be encrypted in part or in whole. Section 3.3
describes some possible structured bodies.
A data structure. This may be as simple as a character string (represented by a name or text element), or complex structure of lists. It may be encrypted in part or in whole. Section 3.3 describes some possible structured bodies.
C
C
A character. Represented by a name element.
A character. Represented by a name element.
CC
CC
A list of mailboxes. When copies of a message are sent to others in
addition to the addresses in the To object, those to whom the copies
are sent will have their addresses recorded here.
A list of mailboxes. When copies of a message are sent to others in addition to the addresses in the To object, those to whom the copies are sent will have their addresses recorded here.
City
City
A city. Represented by a name element.
A city. Represented by a name element.
Comments
Comments
A comment string. Represented by a text element.
A comment string. Represented by a text element.
Count
Count
A count of items of some sort. Represented by a integer element.
A count of items of some sort. Represented by a integer element.
Country
Country
A country. Represented by a name element.
A country. Represented by a name element.
[Page 6] Postel
[Page 6] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
Date
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 result in the
following representation of the date and time:
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 result in the following representation of the date and time:
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
Where 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. To this basic date and time is
appended the offset from Greenwich as plus or minus hh hours and mm
minutes.
Where 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. To this basic date and time is appended 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 algebraically subtract the offset from the local
time.
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 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:00
For example, when the time in Los Angeles is 14:25:00-08:00 the UTC is 22:25:00
or when the time in
Paris is 11:43:00+01:00
the UTC is 10:43:00
or when the time in Paris is 11:43:00+01:00 the UTC is 10:43:00
Device
Device
A device name. Represented by a name element.
A device name. Represented by a name element.
Document
Document
A property list of fields.
A property list of fields.
Distribution Group
Distribution Group
An distribution group is a property list which contains the
following <name,value> pair:
An distribution group is a property list which contains the following <name,value> pair:
name description
---- -----------
GROUP document distribution group name
name description ---- ----------- GROUP document distribution group name
This construct is used so that a distribution group will be a
special case of a mailbox.
This construct is used so that a distribution group will be a special case of a mailbox.
Postel [Page 7]
Postel [Page 7]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
Facsimile Structure
Facsimile Structure
A facsimile data structure. Represented by a property list.
A facsimile data structure. Represented by a property list.
File
File
A file name. Represented by a name element.
A file name. Represented by a name element.
Format
Format
A format indicator. Represented by a name element.
A format indicator. Represented by a name element.
From
From
A list of mailboxes. The From is the name of the author of a
document.
A list of mailboxes. The From is the name of the author of a document.
Graphics Structure
Graphics Structure
A graphics data structure. Represented by a property list.
A graphics data structure. Represented by a property list.
Group
Group
A document distribution group name. Represented by a name element.
A document distribution group name. Represented by a name element.
Host
Host
A host name. Represented by a name element.
A host name. Represented by a name element.
Ident
Ident
The identifier of a person, usually their initials. Represented by
a name element.
The identifier of a person, usually their initials. Represented by a name element.
In-Reply-To
In-Reply-To
The message identifier of previous message. Represented by a text
element.
The message identifier of previous message. Represented by a text element.
Internet Address
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. Further, this
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. Further, this
[Page 8] Postel
[Page 8] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
representation may 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.
representation may 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
Keywords
The key terms used in this message. Represented by a text element.
The key terms used in this message. Represented by a text element.
Mailbox
Mailbox
This is the destination address of a user of the internetwork mail
system. 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.
This is the destination address of a user of the internetwork mail system. 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 one sends a message to someone for the first
time, he may include many items to aid in identifying the correct
recipient. However, once he gets a reply to this message, the reply
will contain an Address (as opposed to Mailbox) which may be used
from then on.
As an example, when one sends a message to someone for the first time, he may include many items to aid in identifying the correct recipient. However, once he gets a reply to this message, the reply will contain an Address (as opposed to Mailbox) which may be used from then on.
A mailbox is a property list. A mailbox might contain the
following <name,value> pairs:
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 number
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 number
The minimum mail box is an Address or a Distribution Group.
The minimum mail box is an Address or a Distribution Group.
Message-ID
Message-ID
The message identifier of this message. This is not related to the
MPM message identification, but is a UIP long term document
identifier. Represented by a text element.
The message identifier of this message. This is not related to the MPM message identification, but is a UIP long term document identifier. Represented by a text element.
Postel [Page 9]
Postel [Page 9]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
MPM-Identifier
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 will be easy to determine
the type of address used.
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 will be easy to determine the type of address used.
Net
Net
A network name. Represented by a name element.
A network name. Represented by a name element.
NLS Block
NLS Block
The information in an NLS node. Represented by a property list.
The information in an NLS node. Represented by a property list.
NLS Node
NLS Node
An NLS block and substructure. Represented by a property list.
An NLS block and substructure. Represented by a property list.
NLS Substructure
NLS Substructure
A list of NLS nodes. Represented by a list.
A list of NLS nodes. Represented by a list.
Org
Org
An organization name. Represented by a name element.
An organization name. Represented by a name element.
Paragraph
Paragraph
A paragraph of text. Represented by a text element.
A paragraph of text. Represented by a text element.
Parcel
Parcel
The basic unit of voice data. Represented by a bitstr element.
The basic unit of voice data. Represented by a bitstr element.
Person
Person
The real name of a person. Represented by a name element.
The real name of a person. Represented by a name element.
Password
Password
A password. Represented by a name element.
A password. Represented by a name element.
Phone
Phone
A phone number. Represented by a name element.
A phone number. Represented by a name element.
[Page 10] Postel
[Page 10] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
Pointer
Pointer
A pointer to information stored outside this data structure. A
property list containing the information necessary to locate the
external data, the information necessary to gain access to the
external data, and the information necessary to apply the correct
interpretation to the external data. For example, this might
include:
A pointer to information stored outside this data structure. A property list containing the information necessary to locate the external data, the information necessary to gain access to the external data, and the information necessary 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
name description ---- ----------- NET network name HOST host name FILE file name USER user name (computer account name) PASSWORD password ACCOUNT account FORMAT format
Port
Port
The address of MPM within the host. Represented by a name element.
The address of MPM within the host. Represented by a name element.
Presentation Descriptor
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.
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
Presentation Element
A property list of media structures.
A property list of media structures.
Protocol
Protocol
The name of the coding scheme used for a medium. Represented by a
name element.
The name of the coding scheme used for a medium. Represented by a name element.
References
References
The message identifiers of other messages. Represented by a list of
text elements.
The message identifiers of other messages. Represented by a list of text elements.
Reply-To
Reply-To
A list of mailboxes. Sometimes it will be desired to direct the
replies of a message to some address other than the from or the
sender. In such a case the reply-to object can be used.
A list of mailboxes. Sometimes it will be desired to direct the replies of a message to some address other than the from or the sender. In such a case the reply-to object can be used.
Postel [Page 11]
Postel [Page 11]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
R 450 Block
R 450 Block
The unit of Rapicom 450 data (585 bits). Represented by a bitstr
element.
The unit of Rapicom 450 data (585 bits). Represented by a bitstr element.
Sender
Sender
A mailbox. The sender will contain the address of the individual
who sent the message. In some cases this is NOT the same as the
author of the message. Under such a condition, the author should be
specified in the from object.
A mailbox. The sender will contain the address of the individual who sent the message. In some cases this is NOT the same as the author of the message. Under such a condition, the author should be specified in the from object.
SID
SID
An NLS statement indetifier. Represented by a integer element.
An NLS statement indetifier. Represented by a integer element.
State
State
A state name. Represented by a name element.
A state name. Represented by a name element.
Subject
Subject
The subject of the message. Represented by a text element.
The subject of the message. Represented by a text element.
Text Structure
Text Structure
A text data structure. Represented by a property list.
A text data structure. Represented by a property list.
To
To
A list of mailboxes. To identifies the addressees of the message.
A list of mailboxes. To identifies the addressees of the message.
User
User
A user name (computer account name). Represented by a name element.
A user name (computer account name). Represented by a name element.
Version
Version
A version number. Represented by a index element.
A version number. Represented by a index element.
Vocoder
Vocoder
A vocoder name. Represented by a name element.
A vocoder name. Represented by a name element.
Voice Structure
Voice Structure
A voice data structure. Represented by a property list.
A voice data structure. Represented by a property list.
[Page 12] Postel
[Page 12] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
X121 Address
X121 Address
This identifies a host in the Public Data Network environment. When
used as a part of 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.
This identifies a host in the Public Data Network environment. When used as a part of 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
ZIP
A zip code. Represented by a name element.
A zip code. Represented by a name element.
2.3. Body Structures
2.3. Body Structures
2.3.1. Simple Elements
2.3.1. Simple Elements
The body could simply be a single data element. For example a
single text element can represent a lengthy character string.
The body could simply be a single data element. For example a single text element can represent a lengthy character string.
<body> := TEXT
<body> := TEXT
or
or
text:"this is the actual text of the body"
text:"this is the actual text of the body"
2.3.2. Structured Text
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.
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>, ...)
<body> := LIST (<paragraph>, <paragraph>, ...)
<paragraph> := TEXT
<paragraph> := TEXT
or
or
list:(text:"paragraph one", text:"paragraph two", ...)
list:(text:"paragraph one", text:"paragraph two", ...)
2.3.3. NLS File Example
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. There are several fields associated
with each node as well.
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. There are several fields associated with each node as well.
Postel [Page 13]
Postel [Page 13]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
An NLS file is:
An NLS file is:
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
)endlist
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 )endlist
An NLS substructure is:
An NLS substructure is:
list:( substructure
<nls-node> node is defined below
.
.
.
)endlist
list:( substructure <nls-node> node is defined below . . . )endlist
An NLS node is:
An NLS node is:
proplist:( node
name:"BLOCK", <nls-block> block defined below
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlist
proplist:( node name:"BLOCK", <nls-block> block defined below name:"SUBSTRUCTURE", <nls-substructure> substructure )endlist
An NLS block is:
An NLS block is:
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
)endlist
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 )endlist
[Page 14] Postel
[Page 14] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
August 1980 A Structured Format for Transmission of Multi-Media Documents Specification
NLS data is:
NLS data is:
proplist:( data
name:"<a data name>", <type depends on data name>
. .
. .
. .
)endlist
proplist: (データ名: 「<aデータ名>」、<タイプはデータ名>を当てにします…)endlist
For text, data is:
テキストのために、データは以下の通りです。
proplist:( data
name:"TEXT", text:"text of statement" text
)endlist
proplist: (データ名: "TEXT"、テキスト: 「声明の原本」テキスト)endlist
2.3.4. Multimedia Structures
2.3.4. マルチメディア構造
One can conceive of graphical information being displayed along with
a running commentary, much as seminars use slides. A slide and its
description are tied together. The coordination of such a
presentation is central to its understanding. This synchronization
should be captured within the document structure.
人はセミナー使用が滑るように実況放送と共に表示されるグラフィカルな情報を想像できます。 スライドとその記述は結びつけられます。 そのようなプレゼンテーションのコーディネートは理解に主要です。 ドキュメント構造の中でこの同期を得るべきです。
There are three fundamentally different types of time ordered
control which are needed within the document structure. These are:
時間の基本的に異なったタイプがどれがドキュメント構造の中で必要であるかを制御するよう命令した3があります。 これらは以下の通りです。
Simultaneous
Sequential
Independent
同時の連続した無党派
Simultaneous data is intended for synchronous presentation. The
implication is that this data is presented in parallel.
同時のデータは同期プレゼンテーションのために意図します。 含意はこのデータが平行に提示されるということです。
Sequential data items will be presented one at a time, in the order
listed. The ordering is strictly left to right.
連続したデータ項目は一度に一つ、リストアップされたオーダーに提示されるでしょう。 注文は厳密に右に残されます。
Independent data can be presented in any time order. It is not
ordered in any manner.
どんな時間オーダーにも独立しているデータを提示できます。 それはどんな方法でも注文されません。
The data is broken into small information units called presentation
elements or PEs. The PEs can be combined in structures to control
the presentation order. A PE is a property list of elements
representing information of various media. For example:
プレゼンテーション要素かPEsと呼ばれる小さい情報単位はデータに細かく分けられます。 プレゼンテーション命令を制御するために構造でPEsを結合できます。 PEは様々なメディアの情報を表す要素の特性のリストです。 例えば:
<pe> := proplist(
name:"VOICE", <voice-structure>,
name:"GRAPHICS", <graphics-structure>
)endlist
<pe>:=proplist(名前: 名前: "VOICE"、<声構造>、「GRAPHICS」<グラフィックス構造>)endlist
Postel [Page 15]
ポステル[15ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
PEs are combined into larger controled presentations by
presentation-descriptors or PDs. A PD is a property list which
specifies the type of time ordering of the PEs in its list.
PEsはプレゼンテーション記述子かPDsによって、より大きいcontroledプレゼンテーションに結合されます。 PDはリストでPEsを注文しながら時間のタイプを指定する特性のリストです。
<pd> := <<seq>> | <<sim>> | <<ind>>
<pd>:=<<seq>>。| <<sim>>。| <<ind>>。
<<seq>> := name:"SEQUENTIAL", <pe>
<<seq>>:=名: 「連続した」<pe>。
<<sim>> := name:"SIMULTANEOUS", <pe>
<<sim>>:=名: 「同時」の<pe>。
<<ind>> := name:"INDEPENDENT", <pe>
<<ind>>:=名: 「独立している」<pe>。
A PE is a property list of the media <name,value> pairs, or PDs.
PEは値のメディア<名、>組、またはPDsの特性のリストです。
<pe> := <<text>> | <<voice>> | <<facsimile>>
| <<graphics>> | <pd>
<pe>:=<<テキスト>>。| <<声の>>。| <<ファクシミリ>>。| <<グラフィックス>>。| <pd>。
<<text>> := name:"TEXT", <text structure>
<<テキスト>>:=名: "TEXT"、<テキスト構造>。
<<voice>> := name:"VOICE", <voice structure>
<<声の>>:=名: "VOICE"、<声の構造>。
<<facsimile>> := name:"FACSIMILE", <facsimile structure>
<<ファクシミリ>>:=名: "FACSIMILE"、<ファクシミリ構造>。
<<graphics>> := name:"GRAPHICS", <graphics structure>
グラフィックス>>:=が命名する<<: 「GRAPHICS」、<グラフィックス構造>。
If more than one <name,value> pair is present within a PE the media
are presented on different output devices in the order specified by
the PE's parent PD. The order of appearance within the proplist is
important only in the event that the parent PD specified sequential
ordering.
1つ以上の<名であるなら、値の>組はメディアがPEの親PDによって指定されたオーダーにおける異なった出力装置に提示されるPEの中に出席しています。 親PDが連続した注文を指定した場合にだけ、proplistの中の外観の注文は重要です。
The structure of multimedia messages which use this scheme will be
demonstrated by a few simple examples chosen to illustrate a basic
text document and the different ordering options. The last example
will suggest some more exotic uses.
基本のテキストドキュメントと異なった注文オプションを例証するために選ばれて、この計画を使用するマルチメディアメッセージの構造はいくつかの簡単な例でデモをするでしょう。 最後の例はそれ以上のエキゾチックな用途を示すでしょう。
[Page 16] Postel
[16ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
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>。
<pd> := <<seq>>
<pd>:=<<seq>>。
<<seq>> := name:"SEQUENTIAL", <pe>
<<seq>>:=名: 「連続した」<pe>。
<pe> := name:"TEXT", <text structure>
<pe>:=名: "TEXT"、<テキスト構造>。
or
または
proplist: (name:"SEQUENTIAL",
proplist:(
name:"TEXT", <text structure>
)endlist
)endlist
proplist: (proplist: 名前: "SEQUENTIAL"、(名前: "TEXT"、<テキスト構造>)endlist)endlist
Simultaneous Ordering
同時の注文
This ordering option is used to indicate when separate streams are
to be presented in parallel. For example, assume GRAPHICS and
VOICE data were to be presented using simultaneously.
この注文オプションは、別々の流れがいつ平行に提示されるかことであることを示すのに使用されます。 例えば、GRAPHICSとVOICEデータが使用が同時に提示されることであったと仮定してください。
<body> := <pd>
<ボディー>:=<pd>。
<pd> := <<sim>>
<pd>:=<<sim>>。
<<sim>> := name:"SIMULTANEOUS", <pe>
<<sim>>:=名: 「同時」の<pe>。
<pe> := name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
<pe>:=名: <声の構造>名: "VOICE"、「GRAPHICS」<グラフィックス構造>。
or
または
proplist:(
name:"SIMULTANEOUS",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist
)endlist
proplist: (名前: proplist: 「SIMULTANEOUS」、(名前: "VOICE"、>が命名する<声の構造: 「GRAPHICS」、<グラフィックス構造>)endlist)endlist
Postel [Page 17]
ポステル[17ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
Sequential Ordering
連続した注文
This option is used to indicate sequential time ordering. The
media in the sub-tree below this PD are not separate streams.
Using again the example above, assume GRAPHICS and VOICE data were
to be presented using sequential ordering.
このオプションは、連続した時間注文を示すのに使用されます。 このPDの下の下位木におけるメディアは別々の流れではありません。再び上記の例を使用して、GRAPHICSとVOICEデータが連続した注文を使用することで提示されることであったと仮定してください。
<body> := <pd>
<ボディー>:=<pd>。
<pd> := <<seq>>
<pd>:=<<seq>>。
<<seq>> := name:"SEQUENTIAL", <pe>
<<seq>>:=名: 「連続した」<pe>。
<pe> := name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
<pe>:=名: <声の構造>名: "VOICE"、「GRAPHICS」<グラフィックス構造>。
or
または
proplist:(
name:"SEQUENTIAL",
proplist:(
name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
)endlist
)endlist
proplist: (名前: proplist: "SEQUENTIAL"、(名前: "VOICE"、>が命名する<声の構造: 「GRAPHICS」、<グラフィックス構造>)endlist)endlist
Independent Ordering
独立している注文
It is apparent that some output devices are very slow in
comparison to others. An example which demonstrates this is
facsimile. The majority of facsimile devices are slow. A
detailed picture transmitted at 9600 baud takes minutes to print.
It is inconvenient for the user to wait on such a device when the
voice or text information which accompanies it is short.
他のものには、いくつかの出力装置が比較で非常に遅いのは、明らかです。 これを示す例はファクシミリです。 ファクシミリ装置の大部分が遅いです。 9600年のボーで送られた詳細な絵は、印刷するには何分もかかります。 それに伴う声かテキスト情報が浅いときに、ユーザがそのような装置で待っているのは、不便です。
For example, if the document a facsimile image and the text
"Hello Frank, here's a copy of that picture you requested." The
user need not wait for the picture. The facsimile machine might
be spooled, in which case he would pick up the picture later. In
a sense the picture was time independent of the text.
例えば、ドキュメントaファクシミリイメージとテキストであるなら、「こんにちは、フランク、ここに、ご要望のその絵のコピーがあります」。 ユーザは絵を待つ必要はありません。 ファクシミリ装置はスプールされるかもしれません、その場合、彼が後で絵を拾うでしょう。 ある意味で、絵はテキストの如何にかかわらず時間でした。
[Page 18] Postel
[18ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
<body> := <pd>
<ボディー>:=<pd>。
<pd> := <<ind>>
<pd>:=<<ind>>。
<<ind>> := name:"INDEPENDENT", <pe>
<<ind>>:=名: 「独立している」<pe>。
<pe> := name:"FACSIMILE", <facsimile structure>
name:"TEXT", <text structure>
<pe>:=名: <ファクシミリ構造>名: "FACSIMILE"、"TEXT"という<テキスト構造>。
or
または
proplist:(
name:"INDEPENDENT",
proplist:(
name:"FACSIMILE", <facsimile structure>
name:"TEXT", <text structure>
)endlist
)endlist
proplist: (名前: proplist: 「無党派」、(名前: "FACSIMILE"、>が命名する<ファクシミリ構造: "TEXT"、<テキスト構造>)endlist)endlist
A Stream Example
流れの例
By making use of the structure and the sequential ordering option
it is possible to initiate a stream. The stream will proceed at
its own pace until concluded.
構造と連続した注文オプションを利用することによって、流れを開始するのは可能です。 流れはマイペースで結論づけられるまで続くでしょう。
<body> := <pd>
<ボディー>:=<pd>。
<pd> := <<seq>>
<pd>:=<<seq>>。
<<seq>> := name:"SEQUENTIAL", <pe>
<<seq>>:=名: 「連続した」<pe>。
<pe> := <pd>
<pe>:=<pd>。
<pd> := <<sim>>
<pd>:=<<sim>>。
<<sim>> := name:"SIMULTANEOUS", <pe>
<<sim>>:=名: 「同時」の<pe>。
<pe> := name:"VOICE", <voice structure>
name:"GRAPHICS", <graphics structure>
<pe>:=名: <声の構造>名: "VOICE"、「GRAPHICS」<グラフィックス構造>。
Postel [Page 19]
ポステル[19ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
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
)endlist
proplist: (名前: proplist: "SEQUENTIAL"、(名前: 名前: 「SIMULTANEOUS」、proplist: (名前: "VOICE"、>が命名する<声の構造: 「GRAPHICS」、<グラフィックス構造>)endlist、「SIMULTANEOUS」proplist: endlist、(名前: "VOICE"、<声の構造>名: 「GRAPHICS」、<グラフィックス構造>)…)endlist)endlist
Such a document structure suggests a slide presentation.
そのようなドキュメント構造はスライドプレゼンテーションを示します。
Multiple Active Stream Example
複数のアクティブな流れの例
This example is exotic but illustrates what is possible. By making
use of the structure and the simultaneous ordering it is possible
to start in parallel two or more separate streams. Each stream
will proceed at its own pace until all are concluded.
この例は、エキゾチックですが、可能なことを例証します。 構造と同時の注文を利用することによって、平行から2つ以上の別々の流れを始めるのは可能です。マイペースですべてが結論づけられるまで、各流れは続くでしょう。
<body> := <pd>
<ボディー>:=<pd>。
<pd> := name:"SIMULTANEOUS", <pe>
<pd>:=名: 「同時」の<pe>。
<pe> = <pd>
<pe>は<pd>と等しいです。
<pd> := name:"SEQUENTIAL", <pe>
<pd>:=名: 「連続した」<pe>。
<pe> = <pd>
<pe>は<pd>と等しいです。
<pd> := name:"SIMULTANEOUS", <pe>
<pd>:=名: 「同時」の<pe>。
<pe> := name:"VOICE",
<voice structure>
name:"GRAPHICS",
<graphics structure>
<pe>:=名: <声の構造>名: "VOICE"、「GRAPHICS」<グラフィックス構造>。
[Page 20] Postel
[20ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
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
)endlist
proplist:; (: 「SIMULTANEOUS」を命名してください、proplist: (: "SEQUENTIAL"を命名してください、proplist:、(proplist: : 「SIMULTANEOUS」、(名前: "VOICE"、>が命名する<声の構造: 「GRAPHICS」、<グラフィックス構造>)endlistが挙げる名前: 「SIMULTANEOUS」、proplist: (: "VOICE"を命名してください、<声の構造> 名前: 「GRAPHICS」、<グラフィックス構造>) endlist、…) proplist: (名前: proplist: 「SIMULTANEOUS」、(名前: "VOICE"、>が命名する<声の構造: 「GRAPHICS」、<グラフィックスは>) endlistを構造化します…)endlist)endlist) endlist名: "SEQUENTIAL"、endlist
2.3.5. The Media
2.3.5. メディア
So far no explicit description has been given for the media classes
which fit into a PE. It is not known what types of media will be
supported in the various document stations in the future. Those for
which support is in part already available are:
今までのところ、PEに収まるメディアのクラスのためにどんな明白な記述も与えていません。 どんなタイプのメディアが将来様々なドキュメントステーションで支持されるかが知られていません。 サポートが一部既に利用可能であるそれらは以下の通りです。
TEXT
VOICE
FACSIMILE
GRAPHICS
テキスト声のファクシミリグラフィックス
Standard formats for data in each of these media must be defined.
それぞれのこれらのメディアによるデータのための標準書式を定義しなければなりません。
Postel [Page 21]
ポステル[21ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
2.3.6. TEXT
2.3.6. テキスト
The text data may be structured according to a variety of protocols
(yet to be defined). The top level of the data structure is a
property list which identifies the protocol, and the version of that
protocol.
さまざまなプロトコル(まだ定義されている)によると、テキストデータは構造化されるかもしれません。 データ構造のトップレベルは、プロトコルを特定する特性のリストと、そのプロトコルのバージョンです。
name:"TEXT", proplist:(
name:"PROTOCOL", <protocol>,
name:"VERSION", <version>,
name:"DATA", <data>
)endlist
名前: "TEXT"、proplist: (名前: 「プロトコル」、名前: >、「バージョン」、<バージョン>が命名する<プロトコル: "DATA"、<データ>)endlist
The first protocol is called PARAGRAPH, and the data is a list of
paragraphs, where each paragraph is a text element.
最初のプロトコルはPARAGRAPHと呼ばれます、そして、データはパラグラフのリストです。そこでは、各パラグラフがテキスト要素です。
name:"DATA", list:(
text: <paragraph>
text: <paragraph>
.
.
.
)endlist
名前: リスト: "DATA"、(テキスト: <パラグラフ>テキスト: <パラグラフ>…)endlist
2.3.7. VOICE
2.3.7. 声
Since a good deal of research has been done towards implementing the
transmission of voice data on the ARPANET, the Network Voice
Protocol (NVP) provides the basis for the standard for voice data
[24].
アルパネットにおける声のデータの伝達を実行することに向かって多くの研究をしたので、Network Voiceプロトコル(NVP)は声のデータ[24]の規格の基礎を提供します。
Voice data a property list which specifies the vocoder being used,
the transmission protocol and the parcel data. The parcel data form
is specific to the protocol used and is grouped in lists.
声のデータaの特性はどれが使用されるボコーダを指定するか、そして、トランスミッションプロトコルと小包データをリストアップします。 小包データフォームは、使用されるプロトコルに特定であり、リストで分類されます。
name:"VOICE", proplist:(
name:"VOCODER", <vocoder>,
name:"PROTOCOL", <protocol>,
name:"VERSION", <version>,
name:"DATA", <data>
)endlist
名前: "VOICE"、proplist: (名前: 名前: "VOCODER"、<ボコーダ>、名前: <プロトコル>、「バージョン」、<バージョン>が命名する「プロトコル」: "DATA"、<データ>)endlist
The NVP protocol has a number of parameters, the version number
specifies a certain set of the parameters used by the vocoder
hardware and software to set up timing and define the type of coding
used. It is not expected that within a document the version number
will change.
NVPプロトコルには、多くのパラメタがあって、バージョン番号はボコーダハードウェアとソフトウェアによって使用される、タイミングをセットアップして、使用されるコード化のタイプを定義するパラメタのあるセットを指定します。 ドキュメントの中では、バージョン番号が変化しないと予想されます。
[Page 22] Postel
[22ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
NVP itself supports negotiation of these parameters to insure both
ends of a network speech connection 'understand' one another. Since
no such interactive negotiation is possible in a document system,
negotiation capabilities have been excluded. As differing hardware
becomes available new versions may be defined.
NVP自身は、ネットワークスピーチ接続の両端がお互いを'理解していること'を保障するためにこれらのパラメタの交渉を支持します。 そのようなどんな対話的な交渉もドキュメント・システムで可能でないので、交渉能力は除かれました。 新しいバージョンは異なったハードウェアが利用可能になると定義されるかもしれません。
For the NVP protocol the data list will take the following form:
NVPプロトコルのために、データの並びは以下の形を取るでしょう:
name:"DATA", list:(
bitstr: <parcel>
bitstr: <parcel>
.
.
.
)endlist
名前: リスト: "DATA"、(bitstr: <小包>bitstr: <小包>…)endlist
The items in the list are parcels. The individual parcels are bit
string data elements whose contents and length are predefined by the
version number. The number of parcels in a parcel group is
available from the item count in the enclosing list header.
リストの項目は小包です。 個々の小包はコンテンツと長さがバージョン番号によって事前に定義されるビット列データ要素です。 小包グループにおける、小包の数は同封のリストヘッダーでの項目カウントによって有効です。
2.3.8. FACSIMILE
2.3.8. ファクシミリ
There are a number of facsimile devices in use. While standards are
being established by CCITT [25], of the devices available today many
are incompatible due to proprietary compression algorithms. The
description of fax data will allow for the possibility of several
protocols.
使用中の多くのファクシミリ装置があります。 独占圧縮アルゴリズムのために、規格がCCITT[25]によって確立されている間、今日利用可能な装置では、多くが両立しないです。ファックスデータの記述はいくつかのプロトコルの可能性を考慮するでしょう。
name:"FACSIMILE", proplist:(
name:"DEVICE", <device>,
name:"PROTOCOL", <protocol>,
name:"DATA", <data>
)endlist
名前: "FACSIMILE"、proplist: (名前: "DEVICE"、名前: >、「プロトコル」、<プロトコル>が命名する<装置: "DATA"、<データ>)endlist
There are few facsimile devices interfaced to computers though, and
the existing experiments in the ARPANET all use the RAPICOM 450. A
first facsimile standard format will be based on the data structure
used for this machine [26]. That is, for device RAPICOM450 and
protocol BLOCK, the data will be:
もっともコンピュータに接続されたファクシミリ装置がわずかしかありません、そして、アルパネットにおける既存の実験はすべて、RAPICOM450を使用します。 最初のファクシミリ標準書式はこのマシン[26]に使用されるデータ構造に基づくでしょう。 データはすなわち、装置RAPICOM450とプロトコルBLOCKに関しては、以下の通りになるでしょう。
name:"DATA", list:(
bitstr:<r450-block>,
bitstr:<r450-block>,
.
.
.
)endlist
名前: リスト: "DATA"、(bitstr: <r450-ブロック>、bitstr: <r450-ブロック>…)endlist
Postel [Page 23]
ポステル[23ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
1980年8月に、マルチメディアの送信のための構造化された形式は仕様を記録します。
Where an r450-block is a 585 bit unit.
r450-ブロックが585ビットのユニットであるところ。
2.3.9. GRAPHICS
2.3.9. グラフィックス
The situation for graphics bears much similarity to facsimile.
Devices on the market today have a variety of user interfaces and
options. A similar structure is defined.
グラフィックスのための状況に、電送する多くの類似性があります。 市販の装置には、今日、さまざまなユーザインタフェースとオプションがあります。 類似構造物は定義されます。
name:"GRAPHICS", proplist:(
name:"DEVICE", <device>,
name:"PROTOCOL", <protocol>,
name:"DATA", <data>
)endlist
名前: 「GRAPHICS」、proplist: (名前: "DEVICE"、名前: >、「プロトコル」、<プロトコル>が命名する<装置: "DATA"、<データ>)endlist
There are several candidate protocols for use in describing graphics
data in documents. One is the Network Graphics Protocol [27],
another is the Graphics Language [28,29], and a third is the
SIGGRAPH Core System [30].
ドキュメントにはグラフィックスデータについて説明することにおける使用のためのいくつかの候補プロトコルがあります。 1つはNetwork Graphicsプロトコル[27]です、そして、別のものはGraphics Language[28、29]です、そして、3分の1はSIGGRAPH Core System[30]です。
[Page 24] Postel
[24ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
3. EXAMPLES & SCENARIOS
3. 例とシナリオ
Example 1: Text Example
例1: テキストの例
Suppose 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
日付: 1979年3月29日-11時46分から8時0分From: ジョン Postel <Postel@ISIF 、gt;、Subject: 木曜日To:に間に合います。 ダニー Cohen <Cohen@ISIB 、gt;、CC: リンダ
Danny:
ダニー:
Please mark your calendar for our meeting Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon.
--jon。
It will be encoded in the structured format. The following will present successive steps in the top down generation of this message. The identification and command portions of the messages will not be expanded here (see [1]).
それは構造化された形式でコード化されるでしょう。 以下はこのメッセージのトップダウン世代における連続したステップを提示するでしょう。 メッセージの識別とコマンド部分はここに広げられないでしょう。([1])を見てください。
1. message
1. メッセージ
2. (identification, command, document)
2. (識別、コマンド、ドキュメント)
3. (ID:<<identification>>,
CMD:<<command>>,
DOC:( date, from, subject, to, cc, body))
3. (ID: <<識別>>、CMD: <<コマンド>>、DOC: (デートしてください、受けることがある、cc、ボディー)
4. (ID:<<identification>>,
CMD:<<command>>,
DOC:(DATE:date,
FROM:from
SUBJECT:subject,
TO:to,
CC:cc,
BODY:body))
4. (ID: <<識別>>、CMD: <<コマンド>>、DOC: (SUBJECT: 対象からの日付:日付、FROM:、TO:、ボディー: CC:cc、ボディー、)
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:
5. (ID: <<識別>>、CMD: <<コマンド>>、DOC: (日付: 1979年3月29日の11時46分から8時0分ボディー: TO:(ネット: ユーザ: アルパネット、ホスト: ISIB、コーエン、人: ダニー・コーエン)、CC:(ネット: ユーザ: アルパネット、ホスト: ISIF、リンダ)、FROM:(ネット: ユーザ: アルパネット、ホスト: ISIF、ポステル、人: ジョン・ポステル)、SUBJECT:が木曜日に会うダニー:
Postel [Page 25]
ポステル[25ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Examples & Scenarios
1980年8月に、マルチメディアの送信のための構造化された形式は例とシナリオを記録します。
Please mark your calendar for our meeting
Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon.))
--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:
6. PROPLIST: (ID: <<識別>>、CMD: <<コマンド>>、DOC: PROPLIST: (日付: リスト: 1979年3月29日の11時46分から8時0分、FROM:(PROPLIST: (人: ユーザ: ポステル、ジョン・ポステルをホスト: : アルパネット、ISIFに捕まえてください)ENDLIST) ENDLIST、木曜日に会うSUBJECT:、TO:リスト: (PROPLIST: (ネット: 人: アルパネット、ホスト: ISIB、ユーザ: コーエン、ダニー・コーエン) ENDLIST) ENDLIST、CC:リスト: (PROPLIST: (ホスト: : アルパネット、ISIFにユーザ: リンダを捕まえてください) ENDLIST) ボディー: ENDLIST、ダニー:
Please mark your calendar for our meeting
Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon.
)ENDLIST
)ENDLIST
--jon。 )、ENDLIST) ENDLIST
[Page 26] Postel
[26ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Examples & Scenarios
1980年8月に、マルチメディアの送信のための構造化された形式は例とシナリオを記録します。
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:
7; 命名..ID..識別..名義..コマンド..命名..名前..命名..1979年3月29日..11時46分から8時0分..名前..リスト..名前..命名..アルパネット..名前..名前..命名..命名..ポステル..名前..名前..ジョン..ポステル..命名; テキスト..会う..名前..記載..名前..命名..アルパネット..名前..名前..命名..命名..コーエン..名前..名前..ダニー..コーエン..名前..CC..記載..名前..名前..アルパネット..名前..名前..名前..名前..リンダ..名前..テキスト..ダニー
Please mark your calendar for our
meeting Thursday at 3 pm.
木曜日の午後3時に私たちのミーティングのためにカレンダーにマークしてください。
--jon."
)endlist
)endlist
--"jon"。 )、endlist) endlist
Postel [Page 27]
ポステル[27ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Examples & Scenarios
1980年8月に、マルチメディアの送信のための構造化された形式は例とシナリオを記録します。
Example 2: Multimedia Example
例2: マルチメディアの例
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
命名..ID..識別..名義..コマンド..命名..名前..名前..1980年8月6日..11時46分から8時0分..名前..記載..名前..命名..アルパネット..名前..名前..命名..命名..ポステル..名前..名前..ジョン..ポステル..名前..テキスト..マルチメディア..命名..記載;
[Page 28] Postel
[28ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
Examples & Scenarios
1980年8月に、マルチメディアの送信のための構造化された形式は例とシナリオを記録します。
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
)endlist
: 「SIMULTANEOUS」を命名してください、proplist。: (: "VOICE"を命名してください、proplist:、(名前: "VOCODER"、名義の名前: : <ボコーダ>、名前: 「プロトコル」、"NVP"名: 「バージョン」、インデックス: 「1インチ名前: "DATA"は: (bitstr: <小包>bitstr: <小包>) endlist) endlist名: 「GRAPHICS」、proplist: (名前: 名前: "DEVICE"、名前: >、「プロトコル」が命名する<装置: <プロトコル>、名前: 名前: 「バージョン」、インデックス: <バージョン>、"DATA"<データ>)endlist)endlist) endlist名を記載します」; 「"SEQUENTIAL"、proplist: (以下を命名してください、「TEXT、proplist: (以下を命名してください、」 プロトコル、」、名前: 名前: 「バージョン」という"PARAGRAPH"が以下に索引をつける、「1インチ、名前: "DATA"、リスト: (テキスト: 「平行ないくつかの声とそれはグラフィックスであるべきでした。」というテキスト:、」 --jon、」、)、endlist) endlist) endlist) endlist) endlist) endlist
Postel [Page 29]
ポステル[29ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
[Page 30] Postel
[30ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
REFERENCES
参照
[1] Postel, J., "Internet Message Protocol," RFC 759, 113,
USC/Information Sciences Institute, August 1980.
[1] ポステル、J.、「インターネットメッセージプロトコル」、RFC759、113、科学が1980年8月に設けるUSC/情報。
[2] Bhushan, A., K. Pogran, R. Tomlinson, and J. White, "Standardizing
Network Mail Headers," RFC 561, NIC 18516, September 1973.
[2]BhushanとA.とK.Pogran、R.トムリンスンとJ.ホワイト、「ネットワークメールヘッダを標準化します」、RFC561、NIC18516、1973年9月。
[3] Myer, T., and D. Henderson, "Message Transmission Protocol,"
RFC 680, NIC 32116, 30 April 1975.
[3] マイヤー、T.とD.ヘンダーソン、「メッセージトランスミッションプロトコル」、RFC680、NIC32116、1975年4月30日。
[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.
[4] クロッカー、D.、J.Vittal、K.Pogran、およびD.ヘンダーソン、「アーパネットテキスト・メッセージの形式の規格」、RFC733、NIC41952(1977年11月21日)。
[5] Barber, D., and J. Laws, "A Basic Mail Scheme for EIN," INWG 192,
February 1979.
1979年2月の[5] バーバー、D.とJ.法、「EINの基本的なメール計画」INWG192。
[6] Braaten, O., "Introduction to a Mail Protocol," Norwegian
Computing Center, INWG 180, August 1978.
[6]Braaten、O.、「メールプロトコルへの序論」、ノルウェーの計算機センタ、INWG180、1978年8月。
[7] Crocker, D., E. Szurkowski, and D. Farber, "An Internetwork Memo
Distribution Capability - MMDF," Sixth Data Communications
Symposium, ACM/IEEE, November 1979.
[7] クロッカー、D.、E.Szurkowski、およびD.ファーバー、「インターネットワークメモ分配能力--、MMDF、」、第6データ通信シンポジウム、ACM/IEEE(1979年11月)
[8] Haverty, J., D. Henderson, and D. Oestreicher, "Proposed
Specification of an Inter-site Message Protocol," 8 July 1975.
[8]Haverty、J.、D.ヘンダーソン、およびD.Oestreicher、「相互サイトメッセージプロトコルの提案された仕様」、1975年7月8日。
[9] Thomas, R., "Providing Mail Services for NSW Users," BBN NSW
Working Note 24, Bolt Beranek and Newman, October 1978.
[9] BBN NSWが注意24を扱って、「メールサービスをNSWユーザに提供し」て、トーマス、R.はBeranekとニューマン、1978年10月をボルトで締めます。
[10] White, J., "A Proposed Mail Protocol," RFC 524, NIC 17140, SRI
International, 13 June 1973.
[10] ホワイト、J.、「提案されたメールプロトコル」、RFC524、NIC17140、SRIインターナショナル、1973年6月13日。
[11] White, J., "Description of a Multi-Host Journal," NIC 23144, SRI
International, 30 May 1974.
[11] ホワイト、J.、「マルチホストジャーナルの記述」、NIC23144、SRIインターナショナル、1974年5月30日。
[12] White, J., "Journal Subscription Service," NIC 23143, SRI
International, 28 May 1974.
[12] ホワイト、J.、「ジャーナル購読サービス」、NIC23143、SRIインターナショナル、1974年5月28日。
[13] Levin, R., and M. Schroeder, "Transport of Electronic Messages
Through a Network," Teleinformatics 79, Boutmy & Danthine (eds.)
North Holland Publishing Co., 1979.
[13]レヴィン、R.とM.シュローダー、「ネットワークを通した電子メッセージの輸送」Teleinformatics79、Boutmy、およびDanthine(eds。) 社、1979を発行する北のオランダ。
[14] Earnest, L., and J. McCarthy, "DIALNET: A Computer Communications
Study," Computer Science Department, Stanford University, August
1978.
[14] まじめ、L.、およびJ.マッカーシー、「DIALNET:」 「Aコンピュータコミュニケーション研究」、コンピュータ理学部、スタンフォード大学、1978年8月。
Postel [Page 31]
ポステル[31ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
References
1980年8月に、マルチメディアの送信のための構造化された形式は参照を記録します。
[15] Crispin M., "DIALNET: A Telephone Network Data Communications
Protocol," DECUS Proceedings, Fall 1979.
[15] クリスピンM.、「DIALNET:」 「電話網データ通信プロトコル」、DECUS議事、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.
[16]Caulkins、D.、「パーソナル・コンピュータ通信(PCNET)は以下を映し出します」。 「Status Report」とコンピュータCalisthenicsのドッブスJournal博士とOrthodontia、v.5、n.6、1980年6月。
[17] Postel, J., "NSW Transaction Protocol (NSWTP)," USC/Information
Sciences Institute, IEN 38, May 1978.
[17] ポステル(J.、「NSW取引プロトコル(NSWTP)」、科学が設けるUSC/情報、IEN38)は1978がそうするかもしれません。
[18] Haverty, J., "MSDTP -- Message Services Data Transmission
Protocol," RFC 713, NIC 34739, April 1976.
[18]Haverty、J.、「MSDTP--サービスデータ伝送プロトコルを通信する」RFC713、NIC34739、1976年4月。
[19] ISO-2014, "Writing of calendar dates in all-numeric form,"
Recommendation 2014, International Organization for
Standardization, 1975.
[19] ISO-2014「オール数値のフォームにカレンダ日付を主題にして書く」Recommendation2014、国際標準化機構1975。
[20] ISO-3307, "Information Interchange -- Representations of time of
the day," Recommendation 3307, International Organization for
Standardization, 1975.
[20] ISO-3307、「情報Interchange--、1日の時間の表現、」、Recommendation3307、国際標準化機構1975
[21] ISO-4031, "Information Interchange -- Representation of local time
differentials," Recommendation 4031, International Organization
for Standardization, 1978.
[21] ISO-4031、「情報Interchange--、現地時間のデフ装置の表現、」、Recommendation4031、国際標準化機構1978
[22] Postel, J., "DOD Standard Internet Protocol," USC/Information
Sciences Institute, IEN 128, NTIS number AD A079730, January 1980.
[22] ポステル、J.、「DODの標準のインターネットプロトコル」、USC/情報Sciences Institute、IEN128、NTIS番号AD A079730、1980年1月。
[23] CCITT-X.121, "International Numbering Plan for Public Data
Networks," Recommendation X.121, CCITT, Geneva, 1978.
[23]CCITT-X.121、「公衆データネットワークのための国際付番プラン」、推薦X.121、CCITT、ジュネーブ、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.
[24] コーエン、D.、「ネットワーク声のための仕様は(NVP)について議定書の中で述べます」、NIC42444、RFC741、NSC68、RR-75-39、科学が設けるUSC/情報、1976年1月。
[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.
[25] CCITT-T.30、「司令官におけるドキュメントファクシミリ伝送のための手順は電話網を切り換えました」、推薦T.30、オレンジブック、7、国際電信電話Consulative委員会、国際電気通信連合、ジュネーブ、1977に対して。
[26] Treadwell, S., "FAX File Format," ARPANET Message, 14 November
1979.
[26] トリードウェル、S.、「ファックスファイル形式」、アルパネットメッセージ、1979年11月14日。
[27] Sproull, R., and E. Thomas, "A Network Graphics Protocol,"
NIC 24308, Xerox Palo Alto Research Center, August 1974.
[27] スプラウル、R.とE.トーマス、「ネットワークグラフィックスプロトコル」NIC24308、ゼロックスパロアルト研究センター、1974年8月。
[Page 32] Postel
[32ページ] ポステル
August 1980
A Structured Format for Transmission of Multi-Media Documents
References
1980年8月に、マルチメディアの送信のための構造化された形式は参照を記録します。
[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.
[28] Bisbey、R.とD.ホリングワース、「指揮統制の配置可能な表示装置無党派ベクタグラフィックスシステム」RR-80-87(科学が1980年7月に設けるUSC/情報)。
[29] Bisbey, R., D. Hollingworth, and B. Britt, "Graphics Language,"
TM-80-18, USC/Information Sciences Institute, July 1980.
[29]BisbeyとR.、D.ホリングワースとB.ブリット、「グラフィックス言語」、TM-80-18、科学が1980年7月に任命するUSC/情報。
[30] Graphics Standard Planning Committee, "Core System," Computer
Graphics, V. 13, N. 3, SIGGRAPH, ACM, August 1979.
[30] グラフィックス標準の実行委員会、「コア・システム」、コンピュータグラフィックス、V.13、N.3、SIGGRAPH、ACM、1979年8月。
Postel [Page 33]
ポステル[33ページ]
August 1980
A Structured Format for Transmission of Multi-Media Documents
マルチメディアの送信のための構造化された形式が記録する1980年8月
[Page 34] Postel
[34ページ] ポステル
一覧
スポンサーリンク
