RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC 822. In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents. Thi...

The Network File System (NFS) Version 4 is a new distributed file system similar to previous versions of NFS in its straightforward design, simplified error recovery, and independence of transport protocols and operating systems for file access in a heterogeneous network. Unlike earlier versions of NFS, the new protocol integrates file locking, strong security, operation coalescing, and delegation capabilities to enhance client performance for narrow data sharing applications on high-bandwidth networks. Locking and delegation make NFS stateful, but simplicity of design is retained through well-defined recovery semantics in the face of client and server failures and network partitions. This paper describes the new features of the protocol, focusing on the security enhancements, integrated locking support, changes to fully support Windows file sharing semantics, support for high performance data sharing, and the design points that enhance performance on the Internet.

We describe in this paper the modelling of multimedia structured documents according to the potential ways to retrieve them. We consider that the works already done on such types of documents do not focus on this point enough. So, our model is based on views that reflect the potential ways of "seeing" multimedia documents. The semantic content of a document is one way of seeing documents. So, another problem that we face here is the way to determine this semantic content by using semantic channels between composing and composed documents. We show an application of our work in the RIME [BMB95] medical context dealing with texts and still images. 1 Introduction There is no need to mention the importance of multimedia systems, due to their multiple applications: digital libraries, multimedia office server, medical applications. The purpose of such multimedia systems is not only to store digital documents [Jai94]. These systems also have to provide different means to access the documents:...

RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC 822. In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents. Thi...

RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC 822. In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents. T...

Increasing demand for Vietnamese electronic information processing has seen answer in a wide array of Vietnamese-capable applications. The inevitable need for integration of Vietnamese into existing environments and the exchange of data among them point to the necessity of standardization. This paper presents the strategic and pragmatic technical considerations that must go into such a standard, and reviews existing conventions/proposals in these important contexts. A full description of the Viet-Std proposal is presented, including 1) an 8-bit, fully precomposed encoding table for Vietnamese Standard Code for Information Interchange (known as VISCII), 2) a 7-bit Vietnamese Quoted-Readable (known as VIQR) standard for data interchange over 7-bit channels, with a seamless interface to the 8-bit encoding, and 3) a keyboard user-interface specification that works transparently with both 1 and 2. Together, these provide a truly unified framework for a Vietnamese information processing environment with simplicity, efficiency, and straightforward integration. The real-world construction of this framework has proven quite successful in an array of compliant applications from a number of group and individual developers across a number of platforms, including Unix and its variants, the X window system, MS-DOS, Windows, and with ongoing work elsewhere. 1

The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.

Status of this Memo