RFC910 日本語訳
0910 Multimedia mail meeting notes. H.C. Forsdick. August 1984. (Format: TXT=24915 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Harry Forsdick
Request for Comments: 910 BBN Laboratories
August 1984
ネットワークワーキンググループハリーForsdickはコメントのために以下を要求します。 910 BBN研究所1984年8月
Multimedia Mail Meeting Notes
マルチメディアはミーティング注意を郵送します。
Status of this Memo
このMemoの状態
This memo is a report on a meeting about the experimental multimedia mail system (and in a sense a status report on that experiment). Distribution of this memo is unlimited.
このメモは実験用マルチメディアメールシステム(そして、ある意味でその実験に関する現状報告)の周りのミーティングに関するレポートです。 このメモの分配は無制限です。
1. Introduction
1. 序論
A meeting was held at Bolt Beranek and Newman on 23-24 July 1984 to discuss recent progress by groups who are building multimedia mail systems and to discuss a variety of issues related to the further development of multimedia systems. Representatives were present from BBN, ISI, SRI and Linkabit. The list of attendees appears at the end of this note.
会合が、1984年7月23日から24日にマルチメディアメールシステムを構築しているグループで最近の進歩について議論して、マルチメディア・システムのさらなる開発に関連するさまざまな問題について議論するためにBolt Beranekとニューマンで行われました。代表はBBN、ISI、SRI、およびLinkabitから出席していました。 出席者のリストはこの注意の終わりに現れます。
The result of this meeting is a series of agreements that will be incorporated in the next set of experiments with multimedia mail as well as a set of items for further action.
さらなる動作のための1セットの項目と同様にマルチメディアメールでこのミーティングの結果は実験の次のセットで法人組織になる一連の協定です。
Note: There are references in this document to notes in a series devoted to multimedia mail. These notes are available on-line in the directory [USC-ISIF]<MMM> and have the names MMM-N.TXT where N is the note number. The file MMM-INDEX.TXT is a list of all of the notes in the series. These public files may be copied via FTP using the FTP username ANONYMOUS and password GUEST.
以下に注意してください。 マルチメディアメールにささげられたシリーズには本書では注意の参照があります。 これらの注意が利用可能なディレクトリのオンライン[USC-ISIF]の<MMM>であり、名前を持っている、MMM-N. TXT、どこ、Nは注意番号であるか。 ファイルMMM-INDEX.TXTはシリーズにおける注意のすべてのリストです。 これらの公共のファイルは、FTPユーザ名更生会とパスワードGUESTを使用することでFTPでコピーされるかもしれません。
2. Review of Status
2. 状態のレビュー
Status reports on work accomplished in the last year were given by each organization.
過去1年間実行された仕事に関する現状報告は各組織によって与えられました。
2.1. BBN
2.1. BBN
The initial implementation of Diamond is complete and runs on the Jericho workstation. Diamond currently supports the exchange of compound documents which contain text, graphics, images, voice and spreadsheet/charts. A demonstration of this system was presented showing both the user's view of Diamond messages and message management as well as the interactions between the components of this distributed system. Diamond currently uses the TOPS-20 implementation of MPM for inter-cluster message transport but the plan is to integrate an implementation of MPM for the Sun Workstation into Diamond. Current activity is focused on porting Diamond to the Sun Workstation. A first version of Diamond for the Sun is nearly
Diamondの初期の実現は、完全であり、ジェリコワークステーションで動きます。 ダイヤモンドは現在、テキスト、グラフィックス、イメージ、声、およびスプレッドシート/図を含むコンパウンドドキュメントの交換を支持します。 このシステムのデモンストレーションは、ユーザのDiamondメッセージとメッセージ管理の視点とこの分散システムのコンポーネントの間の相互作用の両方を示していながら、提示されました。 ダイヤモンドは現在、相互クラスタメッセージ転送にMPMのTOPS-20実現を使用しますが、プランはサンワークステーションのためにMPMの実現をDiamondと統合することです。 現在の活動はDiamondをサンワークステーションに移植するのに焦点を合わせられます。 太陽のためのDiamondの最初のバージョンはほとんどそうです。
Forsdick [Page 1]
Forsdick[1ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
completed and parts (the document editor) were demonstrated running on the Sun. Diamond will be used in the ADDCOMPE testbed with 100-200 users expected in the next year or so. Future plans include building on the experience gained with Diamond in the area of multimedia conferencing, extending the use of multimedia into other application areas and applying the distributed architecture of Diamond to other application areas.
Diamondが望んでいる日曜日の示された走行が100-200 翌年頃に予想されるユーザと共にADDCOMPEテストベッドで使用されたなら、完成して、分けます(ドキュメントエディタ)。 将来のプランは、Diamondと共にマルチメディア会議の領域で行われた経験のときに建てるのを含んでいます、マルチメディアの使用を他の応用分野に広げていて、Diamondの分配された構造を他の応用分野に適用して。
2.2. ISI
2.2. ISI
A new effort aimed at developing a user interface on a Xerox 1108 (Dandelion) workstation has just begun. All of the implementation is being done in Interlisp. Initial work has been done to implement IP and TFTP on the 1108 as well as a document editor that makes use of the Interlisp-D window system. Work on the user interface that was developed on the Perq will be cycling down. The implementation of the MPM on TOPS-20 is essentially complete with the addition of MPM to SMTP mail conversion; no major changes are anticipated. The TOPS-20 MPM will be used as the message transport facility for the 1108 user interface implementation. TFTP will be used to get messages from the 1108 to the TOPS-20.
新しいゼロックス1108(たんぽぽ)ワークステーションの上でユーザーインタフェースを開発するのが目的とされた努力はちょうど始まったところです。 Interlispで実現のすべてをしています。 Interlisp-Dウィンドウシステムを利用するドキュメントエディタと同様に1108でIPとTFTPを実行するために初期の仕事をしました。 Perqで開発されたユーザーインタフェースに対する仕事は循環している下であるのになるでしょう。 TOPS-20におけるMPMの実現はSMTPメール変換へのMPMの添加で本質的には完全です。 大きな変化は全く予期されません。 TOPS-20 MPMは1108年のユーザーインタフェース実現にメッセージ転送施設として使用されるでしょう。 TFTPは、1108年からTOPS-20までメッセージを得るのに使用されるでしょう。
2.3. SRI
2.3. 様
The SRI multimedia mail system consists of three parts: The Multimedia Mail Handler (MMH) which is the user's interface for managing mail, the Structure Editor (SE) which is used to view and compose multimedia messages and the MPM for mail transport. This system is implemented on the Sun Workstation. The first release of the MPM on the Sun will be ready for distribution at the end of this summer. The SE is used to view and compose structures of multimedia objects. Currently there is support for text, voice and graphics.
SRIマルチメディアメールシステムは3つの部品から成ります: メール輸送のためのメールを管理するためのユーザのインタフェースと、マルチメディアメッセージを見て、構成するのに使用されるStructure Editor(SE)とMPMであるMultimediaメールHandler(MMH)。 このシステムはサンワークステーションの上で導入されます。 太陽におけるMPMの最初のリリースは今年の夏の終わりの分配の準備ができるでしょう。 SEは、マルチメディア対象物の構造を見て、構成するのに使用されます。 現在、テキスト、声、およびグラフィックスのサポートがあります。
Another effort at SRI involves integration of applications to run in the ADDCOMPE testbed. Diamond will be the first example of an application which uses multimedia data in the testbed. SRI is interested in examining the issues associated with multimedia systems to determine how multimedia data can be used in other applications that might be put into the testbed.
SRIでの別の努力は、ADDCOMPEテストベッドに立候補するためにアプリケーションの統合にかかわります。 ダイヤモンドはテストベッドでマルチメディアデータを使用するアプリケーションの最初の例になるでしょう。 SRIは、テストベッドに入れられるかもしれない他のアプリケーションでどのようにマルチメディアデータを使用できるかを決定するためにマルチメディア・システムに関連している問題を調べたがっています。
2.4. Linkabit
2.4. Linkabit
Linkabit has recently received a contract to work on protocol evaluation, problems associated with working in a large internet environment, and new real-time end-to-end services. They will be working with Sun workstations. Areas of interest are protocols, multimedia conferencing and domains.
Linkabitは最近プロトコル評価に取り組む契約を受け取りました、大きいインターネット環境、および終わりから終わりに対する新しいリアルタイムのサービスで働くと関連している問題。 彼らはSunワークステーションで働くでしょう。 興味がある地域は、プロトコルと、マルチメディア会議とドメインです。
Forsdick [Page 2]
Forsdick[2ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
3. Discussions and Agreements
3. 議論と協定
3.1. Conversion to the New Multimedia Syntax
3.1. 新しいマルチメディア構文への変換
There was general agreement that in future experiments we would all adopt the revised syntax for multimedia mail as described in the Final Report to SRI Project 5363. It was agreed that RFC767 should be revised to reflect these changes. The timing for switching over should be as soon as possible and should be completed by October 1, 1984.
マルチメディアメールのためにFinal ReportでSRI Project5363に説明されるように私たちが皆、そうする今後の実験で改訂された構文を採用する一般協定がありました。 RFC767がこれらの変化を反映するために改訂されるべきであるのに同意されました。 転換するタイミングは、できるだけ早くであるべきである1984年10月1日までに完成するべきです。
3.2. Graphics Representation
3.2. グラフィックス表現
A wide ranging discussion on the way in which graphics is to be represented in multimedia documents occurred. It was generally agreed that the first style of graphical object to be included in multimedia messages would be a simple line-drawing, such as those that can be produced by the many "draw" programs (e.g. LisaDraw) currently in existence. Attention was focused on the two existing standards (ACM-CORE and GKS) and the interim protocol used in the Diamond system. Two major problems with the existing standards were mentioned:
マルチメディアドキュメントに表されるかのどのグラフィックスがことである途中での広い及んでいる議論は起こりました。 一般に、グラフィカルな物のマルチメディアメッセージに含まれるべき最初のスタイルが簡単な線画であるのに同意されました、現在現存する多くの「ドロー」プログラム(例えば、LisaDraw)で生産できるものなどのように。 注意は2つの既存の規格(ACM-COREとGKS)とDiamondシステムで使用される当座のプロトコルに焦点を合わせられました。 既存の規格に関する2つの大した問題が言及されました:
o In both ACM-CORE and GKS grouping is inadequate or non-existent.
This means that it is difficult or impossible to build up a
composition of several graphical objects and then manipulate
that composite as a single graphical object.
o ACM-COREとGKSの両方では、組分けは、不十分であるか、または実在しません。 これは、数個のグラフィカルな物の構成を確立して、次に、単一のグラフィカルな物としてその合成物を操るのが難しいか、または不可能であることを意味します。
o Neither ACM-CORE or GKS have specified a standard method for
representing graphical drawings in memory (e.g. long term file
storage). This is one of the most important aspects of a
graphical standard for multimedia mail. The focus of graphical
standards so far has been towards driving devices in a
independent manner, not storing graphics in a standard
representation.
o ACM-COREもGKSもメモリ(例えば、長期ファイル記憶装置)にグラフィカルな図面を表すための標準方法を指定していません。 これはマルチメディアメールのグラフィカルな規格の最も重要な局面の1つです。 今までのところのグラフィカルな規格の焦点は独立している方法で運転装置に向かっています、標準の表現におけるグラフィックスを格納しないで。
A presentation of the representation for graphical objects in Diamond was given. The protocol is documented in MMM-18 and MMM-23. Requests for hardcopies of the diagrams in those documents (sigh) can be sent to Travers@BBN.
Diamondのグラフィカルな物の表現のプレゼンテーションをしました。 プロトコルはMMM-18とMMM-23に記録されます。 それらのドキュメント(ため息)のダイヤグラムのハードコピーを求める要求を Travers@BBN に送ることができます。
The discussion then focused on the level of effort required to switch from one representation to another. It was generally agreed that compared to the entire editor used to manipulate graphical objects (e.g., the "draw" program), the part that reads or writes objects from or to files is relatively simple. Most draw programs have a unique internal representation which is built when reading the file representation and used as the source when writing the file
次に、努力のレベルに集中している議論が1つの表現から別のものに切り替わるのが必要です。 一般に、グラフィカルな物(例えば、「ドロー」プログラム)を操作するのに使用される全体のエディタと比べて、ファイルかファイルに物を読み込むか、または書く部分が比較的簡単であるのに同意されました。 ほとんどのドロープログラムには、ファイルを書くとき、ファイル表現を読むとき、組み込まれて、ソースとして使用されるユニークな内部の表現があります。
Forsdick [Page 3]
Forsdick[3ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
representation. It is this relatively small portion of a graphics editor which is impacted by switching from one file representation to another. Thus it seemed that the approach of adopting one interim representation now and planning to switch to a standard representation when work on the standards solve the problems noted above was reasonable.
表現。 それは1つのファイル表現から別のものに切り替わることによって影響を与えられるグラフィックスエディタのこの比較的小さい部分です。 したがって、規格に対する仕事が上に述べられた問題を解決すると、今、1つの当座の表現を採用して、標準の表現に切り替わるのを計画するアプローチが合理的であるように思えました。
After considerable examination of the issues, the following decisions were reached:
問題のかなりの試験の後に、以下の決定に達しました:
1. The representation for graphics used in Diamond and documented
in MMM-18 and MMM-23 will be adopted as an interim
representation for graphics in multimedia mail. It will be
known as the MMGraphics1 protocol.
1. Diamondで使用されて、MMM-18とMMM-23に記録されたグラフィックスの表現はマルチメディアメールによるグラフィックスの当座の表現として採用されるでしょう。 それはMMGraphics1プロトコルとして知られているでしょう。
2. We will actively track development of the GKS standard and also
examine a GKS-subset that has been developed by Sandia Labs.
2. 私たちは、活発にGKS規格の開発を追跡して、また、Sandia Labsによって開発されたGKS部分集合を調べるつもりです。
3. We agreed to settle on an adopted international standard
eventually.
3. 私たちは、結局採用された世界規格について決めるのに同意しました。
3.3. Document Presentation Semantics
3.3. ドキュメント・プレゼンテーション意味論
There was a presentation of the ideas contained in MMM-22: "A Format for the Construction of Multimedia Messages". The resulting discussion addressed the following issues:
MMM-22に含まれた考えのプレゼンテーションがありました: 「マルチメディアメッセージの工事のための形式。」 結果として起こる議論は以下の問題を記述しました:
o Presentation of documents on display devices with different
characteristics (dimensions, resolutions, available fonts,
etc.).
o 異なった特性(寸法、解決、利用可能な字体など)がある書類の提示のディスプレーされた装置。
The essence of the conversation was that there is no single set
of fonts, or page sizes that will cover all of the
possibilities. There was a strong feeling that as long as the
display surface was of reasonable size that a document should
be presented in a "correctly" formatted manner. Rather than
the originator of a document specifying hard page boundaries,
the intent of the originator regarding formatting and grouping
of objects in the document should be preserved and used when
the document is actually presented on a display device. A
window on a bitmap display and a hardcopy page printer are both
examples of display devices.
会話の本質は可能性のすべてを覆う字体、またはページ・サイズのどんなただ一つのセットもないということでした。 表示面がドキュメントが「正しく」フォーマットされた方法で提示されるべきである妥当なサイズのものであったときに、それ同じくらい長い強気がありました。 困難なページ・バウンダリを指定するドキュメントの創始者よりむしろ、ドキュメントが実際にディスプレイ装置の上に提示されるとき、物がドキュメントでフォーマットして、分類されることに関する創始者の意図は、保存されて、使用されるべきです。 ビットマップ・ディスプレーの上の窓とハードコピーページ印刷機はディスプレイ装置に関する両方の例です。
o The desire to represent the kinds of documents that currently
exist in the world of hardcopy as well as to represent documents
that can take advantage of the new possibilities of electronic
creation, storage and presentation.
o 現在ハードコピーの世界に存在するドキュメントの種類を表して、電子創造、格納、およびプレゼンテーションの新しい可能性を利用できるドキュメントを表す願望。
Forsdick [Page 4]
Forsdick[4ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
Several points were made:
数ポイントは指摘されました:
1. One of the first goals for multimedia systems should be to
represent the types of documents that are prevalent in the
hardcopy world. People are already familiar with these
documents and will expect multimedia systems to, at least, be
able to deal with them.
1. マルチメディア・システムのための初ゴールの1つはハードコピー世界で一般的なドキュメントのタイプの代理をすることであるべきです。 人々は、既にこれらのドキュメントになじみ深く、マルチメディア・システムがそれらに少なくとも対処できると予想するでしょう。
2. In an effort to provide the capabilities of electronically
originated documents based on the hardcopy model of documents,
we should not eliminate the great potential of electronic
documents that have much greater reactive qualities. For
example, a document where a graphical figure and a textual
explanation of that figure are linked so that as long as the
explanation is being read the figure is visible.
2. ドキュメントのハードコピーモデルに基づく電子的に溯源されたドキュメントの能力を提供するための努力では、私たちははるかに大きい反応品質を持っている電子化文書の素晴らしい潜在能力を排除するべきではありません。 例えば、説明が図に読み込まれているときグラフィカルな図とその図の原文の説明が同じくらい長くなるように繋がっているドキュメントは目に見えます。
3. In many situations being able to carry away a paper copy of a
document is a requirement even if the document was not
primarily intended to be presented in hardcopy.
3. 多くの状況で、ハードコピーにドキュメントが提示されることを主として意図しなかったとしても、ドキュメントの紙のコピーを運び去ることができるのは、要件です。
The following agreements were made:
以下の協定をしました:
1. A method for recording the author's intent regarding the
presentation of a document should be developed. This
representation would defer decisions on final presentation
bindings of size, resolution and fonts to the reader's document
presenter.
1. ドキュメントのプレゼンテーションに関する作者の意図を記録するための方法は開発されるべきです。 この表現はサイズ、解決、および字体の最終的なプレゼンテーション結合の決定を読者のドキュメント贈呈者に延期するでしょう。
Topics addressed by this representation will include:
この表現で記述された話題は以下を含むでしょう。
o Grouping of objects
o 物の組分け
o Limited Font attributes (e.g., normal, bold, italic)
o 株式会社Font属性(例えば、大胆で、イタリック体の標準)
o Headings, Footings
o 見出し、立脚地
o Sectioning
o 区分
Of course the reader's document presenter is free to ignore any
of the author's intentions it cannot deal with. The point of
this representation is to record the author's desires but to
defer final decisions on how to use the intentions until the
capabilities of the reader are known.
もちろん読者のドキュメント贈呈者は自由にそれが対処できない作者の意志のいずれも無視できます。 この表現のポイントが作者の願望を記録することですが、読者の能力までどう意志を使用するかに関する最終決定を延期するのは知られています。
This representation will lie some where between the rather
loose spatial and temporal positioning commands currently in
the protocol (Sequential, Simultaneous and Independent) and the
そしてこの表現が間にかなりゆるい空間的で時の位置決めが現在プロトコルで命令するところにいくつかある、(連続する、Simultaneousと無党派)。
Forsdick [Page 5]
Forsdick[5ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
absolute positioning of a system that defines rigid page
boundaries and absolute positions for object placement on a
page.
1ページにおける物のプレースメントのために堅いページ・バウンダリと絶対位置を定義するシステムの絶対位置決め方式。
2. We will NOT try to make this representation handle all of the
issues addressed by modern document formatting systems.
Instead we will skim off some of the most useful ideas but
perhaps limit the flexibility present in these complex
formatting systems.
2. 私たちはこの表現に現代のドキュメント形式システムによって記述された問題のすべてを扱わせようとしないでしょう。私たちは、代わりに、最も役に立つ考えのいくつかをすくい取りますが、恐らくこれらの複雑な形式システムの現在の柔軟性を制限するつもりです。
3. The document representation will be able to describe
relationships between objects that make use of the capabilities
of electronic document presentation, such as simultaneous
presentation (i.e., two objects which are visible at the same
time) and overlay presentation (i.e., two (possibly
transparent) objects which occupy the same area in a document,
which may also be separated under viewer control).
3. ドキュメント表現は電子化文書プレゼンテーションの能力を利用する物の間の関係について説明できるでしょう、同時のプレゼンテーション(すなわち、2個の同時に目に見える物)やオーバレイプレゼンテーション(すなわち、また、ビューアー制御装置の下で切り離されるかもしれないドキュメントで同じ領域を占領する2個の(ことによると透明)の物)のように。
4. Methods should be developed for all aspects of the document
representation for presenting the document in a hardcopy form.
This applies both electronic documents that fit the tradition
hardcopy model as well as those that make use of the more
reactive features of the representation.
4. 方法はハードコピーフォームにドキュメントを提示するドキュメント表現の全面に開発されるべきです。 これは伝統ハードコピーモデルに合う電子化文書と表現の、より反応している特徴を利用するものの両方を適用します。
3.4. Directory Service
3.4. ディレクトリサービス
There is an increasing need to be able to determine attributes of users, hosts and domains throughout the DARPA Internet. For example, when composing the header fields of a message it is useful to be able to inquire about the mail box location of a person to whom the message is addressed. Likewise, there is need to determine the services provided by a host so that requests that will never be satisfied can be avoided.
DARPAインターネット中でユーザ、ホスト、およびドメインの属性を決定できる増加する必要があります。 メッセージのヘッダーフィールドを構成するとき、例えば、メッセージが記述される人のメールボックスの位置について問い合わせをすることができるのは役に立ちます。 同様に、決して応じない要望は避けることができるようにホストによって提供されたサービスを決定する必要があります。
The feeling of the group was that work on the Internet Domain system (being done at ISI and Berkeley) would answer some of these problems and that we should examine the design documents to see how that system might help us (see RFCs 882 and 883). The WhoIs server is useful, but only for information about the text mail box of a person (see RFC812).
グループ感はインターネットDomainシステム(ISIにして、バークレー)への作業がこれらの問題のいくつかに答えて、私たちがそのシステムがどう私たちを助けるかもしれないかを(RFCs882と883を見てください)見るためにデザインドキュメントを調べるべきであるということでした。 WhoIsサーバは役に立ちますが、テキストの情報だけに関して、人の箱を郵送してください(RFC812を見てください)。
Forsdick [Page 6]
Forsdick[6ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
3.5. New Media Types
3.5. ニューメディアタイプ
The discussion dealt with three topics: A proposal for a new media type, ideas for other new media types and provisions for dealing with unknown media types.
議論は3つの話題に対処しました: ニューメディアタイプのための提案、他のニューメディアタイプのための考え、および未知のメディアタイプに対処するための条項。
A description of the Diamond SpreadSheet/Chart media type was presented. This is documented in MMM-24. In this media it is possible to represent a table containing numbers, labels, dates and formulas. A unique attribute of this media type is that the spreadsheet model as well as the data are transmitted. The reader of a document containing a spreadsheet object can test what effect different data would have on conclusions suggested by the spreadsheet object. A spreadsheet may appear as a table and/or one of several alternative business charts (line graph, scatter graph, bar chart or pie chart). Rulings may be added to the tabular representation so that it is possible to achieve the appearance of sophisticated tabular data presentation. During the discussion, the point was made that a minimal implementation of the spreadsheet object could ignore the formulas and just present the values of the cells, thus allowing a minimal presentation of the tabular and chart information.
Diamond SpreadSheet/図のメディアタイプの記述は提示されました。 これはMMM-24に記録されます。 このメディアでは、数、ラベル、日付、および定石を含むテーブルを表すのは可能です。 このメディアタイプのユニークな属性はスプレッドシートにデータが送られるのと同じくらいよくモデル化されるということです。 スプレッドシート物を含むドキュメントの読者は異なったデータがスプレッドシート物によって示された結論のときに持っているすべての効果をテストできます。 スプレッドシートはいくつかの代替のビジネス図(構成比層グラフ、散布図、棒グラフまたは円グラフ)のテーブル、そして/または、1つとして現れるかもしれません。 判決が表表現に追加されるかもしれないので、高性能の表データの表現の外観を獲得するのは可能です。 議論の間、スプレッドシート物の最小限の器具が定石を無視して、ただセルの値を提示するかもしれないというポイントは、指摘されました、その結果、表と図の情報の最小量のプレゼンテーションを許容します。
Ideas for new media types included:
ニューメディアタイプのための考えは:だった
Form
フォーム
A set of fields which are Name-Value pairs. Forms can be used
for presentation and/or acceptance of information. The act of
filling out a form might be used (under user approval) to
trigger sending the completed form to the appropriate person
who handles such forms.
Name-値である1セットの分野は対にされます。 情報のプレゼンテーション、そして/または、承認にフォームを使用できます。 書類に書き込む行為はそのようなフォームを扱う適切な人に完成したフォームを送るのにおいて引き金となるのにおいて使用されているかもしれません(ユーザ承認での)。
Animated Graphics
アニメのグラフィックス
A line drawing that has temporal information encoded in the
presentation of its components. The idea is that parts of a
graphics object could move about the object during its
presentation. For example, an arrow could move about a map
showing a route to be followed. There was some discussion
about how this would interact with other media. For example,
how could an arrow moving about a map be coordinated with voice
instructions on how to get from one place to another. There
were no decisions about how best to accomplish this.
それを描く線で、コンポーネントのプレゼンテーションで時の情報をコード化します。 考えはグラフィックス物の部分がプレゼンテーションの間物を動き回らせるかもしれないということです。 例えば、矢は続かれるようにルートを示している地図を動き回らせるかもしれません。 これがどう他のメディアと対話するだろうかについての何らかの議論がありました。 例えば、1つの場所から別のものにどう得るかに関する声の指示でどうしたら地図の周りの矢の運動を調整できますか? どのようにこれを最もよく達成するかに関する決定が全くありませんでした。
Finally, we agreed that all of our systems should be prepared to accept (and possibly ignore) media types that are not currently implemented. The common way of dealing with this is to include a statement of the form "An object of type <Type> appears here". With
そして、最終的に、私たちが、私たちのシステムのすべてが受け入れるように準備されるべきであるのに同意した、(ことによると無視する、)、現在実行されないメディアタイプ。 これに対処する一般的な方法はフォームの声明を含むように、「タイプ<Type>の物はここに現れる」ということです。 with
Forsdick [Page 7]
Forsdick[7ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
the regularized syntax that has been adopted many of the common attributes of all object types will be able to be understood but the actual type may not be implemented. In Diamond we would like to use the MPM to transfer Diamond messages between Diamond and non-Diamond clusters. Currently if we were to include a spreadsheet in one of these messages, all of the other implementations of multimedia mail would probably end in the debugger when they went to process our messages, rather than indicate that there was something that they didn't quite understand.
多く採用されたすべてのオブジェクト・タイプの一般的な属性の整理された構文は理解できるでしょうが、実際のタイプは実行されないかもしれません。 Diamondでは、Diamondと非ダイヤモンドクラスタの間にDiamondメッセージを移すのにMPMを使用したいと思います。 彼らが全く理解したというわけではないことがあったのを示すよりむしろ私たちのメッセージを処理しに行ったとき、現在、私たちがこれらのメッセージの1つでスプレッドシートを入れるなら、マルチメディアメールの他の実現のすべてがたぶんデバッガに終わるでしょうに。
3.6. MPM Support
3.6. mpmは支持します。
By the end of the summer there will be two implementation of the MPM: on TOPS-20 and on the Sun Workstation. We agreed to try to set up the following operational MPMs:
夏の終わりまでには、MPMの2実現があるでしょう: 先端-20とサンワークステーションに関して。 私たちは、以下の操作上のMPMsをセットアップしようとするのに同意しました:
Organization Host MPM Implementation
組織ホストmpm、実現
ISI ISIF TOPS-20
ISI ISIB TOPS-20
SRI ? Sun Workstation
BBN ? Sun Workstation
DARPA ? Sun Workstation
Linkabit DCN6 Sun Workstation
ISI ISIF先端-20ISI ISIB先端-20様? サンワークステーションBBN? サンワークステーションDARPA? サンワークステーションLinkabit DCN6サンワークステーション
The idea behind this agreement is to get wide geographic coverage to allow us to use multimedia mail on a regular basis and to test the impact of realistic use of multiple communicating MPMs using the Internet.
この協定の後ろの考えは私たちが広い地理的な適用範囲で定期的にマルチメディアメールを使用して、複数の交信MPMsの現実的な使用の影響をテストするのをインターネットを使用することで得ることです。
3.7. Floating Point Data Type
3.7. 浮動小数点データ型
In the representation for data defined in RFC759, there is no way to represent floating point numbers. We agreed that a new data type should be added, called Float64 which is the 64-bit IEEE standard floating point number representation.
RFC759で定義されたデータの表現には、浮動小数点を表す方法が全くありません。 64ビットのIEEE標準の浮動小数点表現であるFloat64は、私たちが、新しいデータ型が加えられるべきであるのに同意したと呼びました。
3.8. Captions
3.8. 見出し
The idea of including a text caption as an optional property of every object was discussed. There are several uses of such a caption:
あらゆる物の任意の特性としてテキスト見出しを含んでいるという考えについて議論しました。 そのような見出しのいくつかの用途があります:
o For media like voice which do not have an implicit visual
representation, it is useful to include a caption indicating
something about the object. This caption can serve as a visual
indication of the presence of the non-visual object.
o 声のような暗黙の視覚表現を持っていないメディアに、物の周りに何かを示す見出しを含んでいるのは役に立ちます。 この見出しは非視覚の物の存在の視覚しるしとして機能できます。
Forsdick [Page 8]
Forsdick[8ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
o When an implementation of a multimedia message system doesn't
support a given media type, it can be useful to give some
information about the object in the form of a text passage.
o マルチメディアメッセージシステムの実現が与えられたメディアタイプを支持しないとき、テキスト通路の形で物の何らかの情報を教えるのは役に立つ場合があります。
o In some situations, it is important to present an outline of a
document. Captions associated with each object could be used to
generate a shortened abstract of the document.
o いくつかの状況で、ドキュメントのアウトラインを提示するのは重要です。 ドキュメント短くされた要約を作るのに各物に関連している見出しを使用できました。
We agreed to add to all object types an optional property whose name is "Caption" and whose value is of type Text String.
私たちは、名前が「見出し」であり、タイプText Stringには値がある任意の特性をすべてのオブジェクト・タイプに追加するのに同意しました。
3.9. More Users of Multimedia Mail
3.9. マルチメディアメールの、より多くのユーザ
We need to increase the use of multimedia mail to gain more experience with issues that need attention. This can be done by:
私たちは、注意を必要とする問題の、より多くの経験をするためにマルチメディアメールの使用を増加させる必要があります。 以下はこれができます。
o Encouraging more sites to participate in the experiments. There
are several possible sites which have Sun workstations that
could be configured to run an MPM and one of the multimedia
message systems.
o より多くのサイトが実験に参加するよう奨励します。 MPMを走らせるために構成できたSunワークステーションとマルチメディアメッセージシステムの1つを持っているいくつかの可能なサイトがあります。
o Making the MPMs perform translations to and from SMTP text-only
mail. At BBN, the Diamond Import/Export component performs
translations in both directions and this has proved very useful
in testing the operation of our system. In addition, the
inclusion of statements such as <Graphics appears here> might
spark interest from text-only mail recipients, although care
should be taken not to offend anybody with this kind of "class
differentiation".
o MPMsにメールとSMTPテキストのみメールから翻訳を実行させます。 BBNでは、Diamond Import/Exportの部品は両方の指示の翻訳を実行します、そして、これは私たちのシステムの操作をテストする際に非常に役に立つと判明しました。 添加、<Graphicsがここに現れさせる声明の包含では、>はテキストのみメール受取人からの関心をかきたてるかもしれません、この種類の「クラス分化」をもっているだれも怒らせないように注意するべきですが。
To the extent possible, the Sun Workstation MPM will be modified to perform translations to and from SMTP mail. The TOPS-20 MPM already does the translation from multimedia mail to text-only mail. It may be possible to add translation in the other direction.
可能な範囲内で、サンワークステーションMPMは、メールとSMTPメールからの翻訳を実行するように変更されるでしょう。 TOPS-20 MPMは既にマルチメディアメールからテキストのみメールまでの翻訳をします。 もう片方の指示の翻訳を加えるのは可能であるかもしれません。
3.10. Multimedia Exploder Mailing List
3.10. マルチメディア発破器メーリングリスト
A mailing list devoted to Multimedia Mail will be set up at ISI. This will be of the "exploding" variety so that sending a message to the list will cause everybody on the list to receive a copy. To get on or off the list send a note to MMM-People-Request@USC-ISIF.ARPA. The exploder mailbox is MMM-People@USC-ISIF.ARPA.
MultimediaメールにささげられたメーリングリストはISIにセットアップされるでしょう。 これは、リストの上のみんながメッセージをリストに送るのにコピーを受け取るように、「爆発している」バラエティーのものになるでしょう。 リストで得るには、 MMM-People-Request@USC-ISIF.ARPA に手紙を書いてください。 発破器メールボックスは MMM-People@USC-ISIF.ARPA です。
Forsdick [Page 9]
Forsdick[9ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
3.11. Next Experiment
3.11. 次の実験
The next experiment will be in January 1985. At that time we will try to demonstrate the following new features:
1985年1月に、次の実験はあるでしょう。 その時、私たちは以下の新機能を示そうとするでしょう:
o Use of the revised multimedia syntax described in section 3.1.
o セクション3.1で説明された改訂されたマルチメディア構文の使用。
o Inclusion of Graphics objects, in addition to Text, Images and
Voice.
o Text、イメージズ、およびVoiceに加えたGraphics物の包含。
o Use of the, as yet unspecified, document presentation semantics
described in section 3.3.
o 使用、まだ不特定であるとして、セクション3.3で説明されたプレゼンテーション意味論を記録してください。
o Use of the Sun Workstation MPMs.
o サンワークステーションMPMsの使用。
4. Further Actions
4. さらなる動作
Several of the agreements reached require further action. I have added dates which seem reasonable.
達したいくつかの合意がさらなる動作を必要とします。 私は妥当に思える日付を加えました。
Revision of RFC759 to include Float64 data type.
Person: Greg Finn and Jon Postel.
Due Date: 1 September 84.
Float64データ型を含むRFC759の改正。 人: グレッグフィンランド人とジョン・ポステル。 期日: 1984年9月1日。
Conversion to the new Multimedia Syntax
Person: All groups.
Due Date: 1 September 84.
新しいMultimedia Syntax Personへの変換: すべてが分類されます。 期日: 1984年9月1日。
Revision of RFC767 to reflect revised Multimedia Syntax and
optional Caption property
Person: Jose Garcia-Luna and Jon Postel
Due Date: 1 October 84.
反映するRFC767の改正はMultimedia Syntaxと任意のCaptionの特性のPersonを改訂しました: ホセ・ガルシア-ルーナとジョンポステルDue Date: 1984年10月1日。
Specification of Document Presentation Semantics (Section 3.3)
Person: Harry Forsdick
Due Date: 1 October 84.
ドキュメント・プレゼンテーション意味論(セクション3.3)人の仕様: ハリーForsdick Due Date: 1984年10月1日。
Acquisition of GKS and GKS-subset documentation
Person: Lou Schreier
Due Date: 1 September 84
GKSとGKS部分集合ドキュメンテーションPersonの獲得: ルウシュライヤーDue Date: 1984年9月1日
Completion of initial implementation of Sun Workstation MPM
Person: Andy Poggio
Due Date: 15 September 84
サンワークステーションMPM Personの初期の実現の完成: アンディPoggio Due Date: 1984年9月15日
Multimedia Exploder Mailing List
Person: Greg Finn
Due Date: 15 August 84 < COMPLETED >
マルチメディア発破器メーリングリスト人: グレッグフィンランド人Due Date: 1984年8月15日<は>を完成しました。
Forsdick [Page 10]
Forsdick[10ページ]
RFC 910 August 1984 Multimedia Mail Meeting Notes
注意を満たすRFC910 1984年8月のマルチメディアメール
Addition of MPM<==>SMTP translation logic to Sun Workstation MPM
Person: Mike O'Connor
Due Date: 1 November 84
>SMTP翻訳MPM<=論理のサンワークステーションMPM Personへの添加: マイクオコナーDue Date: 1984年11月1日
Demonstrate Text-Graphics-Image-Voice Document Exchange
Person: All
Due Date: January 85
テキストグラフィックスイメージ声のドキュメント交換人のデモをしてください: すべての期日: 1月85日
5. Attendees
5. 出席者
Harry Forsdick BBN Forsdick@BBN (617) 497-3638 David L. Mills Linkabit Mills@ISID (703) 734-9000 Louis Schreier SRI Schreier@SRI-SPAM (415) 326-6200 Philip Au SRI Psa@SRI-SPAM (415) 326-6200 Greg Finn ISI Finn@ISIF (213) 822-1511 Mike O'Connor Linkabit OConnor@DCN9 (703) 734-9000 Ray Tomlinson BBN Tomlinson@BBN (617) 497-3363 Ginny Travers BBN Travers@BBN (617) 497-2647 Terry Crowley BBN TCrowley@BBN (617) 497-2677 Andy Poggio SRI Poggio@SRI-TSC (415) 859-5094 Jose Garcia-Luna SRI Garcia@SRI-TSC (415) 859-5647 George Robertson BBN GRobertson@BBN (617) 497-3632
ハリー・Forsdick BBN Forsdick@BBN (617)497-3638デヴィッドL; Linkabit Mills@ISID (703)734-9000ルイスシュライヤー様の Schreier@SRI-SPAM (415)326-6200フィリップAu様の Psa@SRI-SPAM (415)326-6200グレッグフィンランド人ISI Finn@ISIF (213)822-1511マイクオコナーLinkabit OConnor@DCN9 (703)734-9000レイトムリンスンBBN Tomlinson@BBN (617)497-3363ジニーTravers BBN Travers@BBN (617)497-2647テリー・クローリーBBN TCrowley@BBN (617)497-2677アンディPoggio様の Poggio@SRI-TSC (415)859-5094ホセガルシア-ルーナ様の Garcia@SRI-TSC (415)859-5647ジョージロバートソンBBN GRobertson@BBN (617)497-3632を製粉します。
Forsdick [Page 11]
Forsdick[11ページ]
一覧
スポンサーリンク
