📄 rfc767.txt
字号:
proplist:( data name:"<a data name>", <type depends on data name> . . . . . . )endlist For text, data is: proplist:( data name:"TEXT", text:"text of statement" text )endlist 2.3.4. Multimedia Structures 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: 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: <pe> := proplist( name:"VOICE", <voice-structure>, name:"GRAPHICS", <graphics-structure> )endlistPostel [Page 15] August 1980A Structured Format for Transmission of Multi-Media DocumentsSpecification 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. <pd> := <<seq>> | <<sim>> | <<ind>> <<seq>> := name:"SEQUENTIAL", <pe> <<sim>> := name:"SIMULTANEOUS", <pe> <<ind>> := name:"INDEPENDENT", <pe> A PE is a property list of the media <name,value> pairs, or PDs. <pe> := <<text>> | <<voice>> | <<facsimile>> | <<graphics>> | <pd> <<text>> := name:"TEXT", <text structure> <<voice>> := name:"VOICE", <voice structure> <<facsimile>> := name:"FACSIMILE", <facsimile structure> <<graphics>> := name:"GRAPHICS", <graphics structure> If 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. 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 August 1980 A Structured Format for Transmission of Multi-Media Documents Specification Plain Text Message A simple text body could be represented in a single text data structure. To give the simplest example of a structured body we show a simple text body represented in the multimedia structure. <body> := <pd> <pd> := <<seq>> <<seq>> := name:"SEQUENTIAL", <pe> <pe> := name:"TEXT", <text structure> or proplist: (name:"SEQUENTIAL", proplist:( name:"TEXT", <text structure> )endlist )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. <body> := <pd> <pd> := <<sim>> <<sim>> := name:"SIMULTANEOUS", <pe> <pe> := name:"VOICE", <voice structure> name:"GRAPHICS", <graphics structure> or proplist:( name:"SIMULTANEOUS", proplist:( name:"VOICE", <voice structure> name:"GRAPHICS", <graphics structure> )endlist )endlistPostel [Page 17] August 1980A Structured Format for Transmission of Multi-Media DocumentsSpecification 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. <body> := <pd> <pd> := <<seq>> <<seq>> := name:"SEQUENTIAL", <pe> <pe> := name:"VOICE", <voice structure> name:"GRAPHICS", <graphics structure> or proplist:( name:"SEQUENTIAL", proplist:( name:"VOICE", <voice structure> name:"GRAPHICS", <graphics structure> )endlist )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. 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.[Page 18] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification <body> := <pd> <pd> := <<ind>> <<ind>> := name:"INDEPENDENT", <pe> <pe> := name:"FACSIMILE", <facsimile structure> name:"TEXT", <text structure> or proplist:( name:"INDEPENDENT", proplist:( name:"FACSIMILE", <facsimile structure> name:"TEXT", <text structure> )endlist )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> := <<seq>> <<seq>> := name:"SEQUENTIAL", <pe> <pe> := <pd> <pd> := <<sim>> <<sim>> := name:"SIMULTANEOUS", <pe> <pe> := name:"VOICE", <voice structure> name:"GRAPHICS", <graphics structure>Postel [Page 19] August 1980A Structured Format for Transmission of Multi-Media DocumentsSpecification 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 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. <body> := <pd> <pd> := name:"SIMULTANEOUS", <pe> <pe> = <pd> <pd> := name:"SEQUENTIAL", <pe> <pe> = <pd> <pd> := name:"SIMULTANEOUS", <pe> <pe> := name:"VOICE", <voice structure> name:"GRAPHICS", <graphics structure>[Page 20] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification 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 2.3.5. The Media 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: TEXT VOICE FACSIMILE GRAPHICS Standard formats for data in each of these media must be defined.Postel [Page 21] August 1980A Structured Format for Transmission of Multi-Media DocumentsSpecification 2.3.6. TEXT 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 The first protocol is called PARAGRAPH, and the data is a list of paragraphs, where each paragraph is a text element. name:"DATA", list:( text: <paragraph> text: <paragraph> . . . )endlist 2.3.7. VOICE 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]. 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. name:"VOICE", proplist:( name:"VOCODER", <vocoder>, name:"PROTOCOL", <protocol>, name:"VERSION", <version>, name:"DATA", <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.[Page 22] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents Specification 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. For the NVP protocol the data list will take the following form: name:"DATA", list:( bitstr: <parcel> bitstr: <parcel> . . . )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 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. name:"FACSIMILE", proplist:( name:"DEVICE", <device>, name:"PROTOCOL", <protocol>, name:"DATA", <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: name:"DATA", list:( bitstr:<r450-block>, bitstr:<r450-block>, . . . )endlistPostel [Page 23] August 1980A Structured Format for Transmission of Multi-Media DocumentsSpecification Where an r450-block is a 585 bit unit. 2.3.9. GRAPHICS 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 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].[Page 24] Postel August 1980 A Structured Format for Transmission of Multi-Media Documents⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -