This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards " for the standardization state and status of this protocol. Distribution of this memo is unlimited. This memo describes an extension to the message format defined in RFC 1521 [1], to allow the representation of character sets other than ASCII in RFC 822 (STD 11) message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1521. 1.

Abstract not found

draft-ietf-notary-mime-delivery-05.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt " listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based " systems), the DSN protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign " addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling " of foreign notifications through Internet mail.

Abstract not found

Abstract not found

Abstract 1.1 Our proxy In recent years, proxies have become more prevalent. Generally, these systems are used to process data tlowing between two end-points using an intermediary. More specifically, they can be used to filter or process traffic flowing to and from a network-limited host. Benefits include more efficient use of network resources, re-duced cost, and increased security. In this paper, we describe the design and capabilities of such a system, how it has been applied to the mobile environment, and provide an evaluation of the work. 1

The SHARE project seeks to apply information technologies in helping design teams gather, organize, re-access, and communicate both informal and formal design information to establish a "shared understanding" of the design and design process. This paper presents the visions of SHARE, along with the research and strategies undertaken to build an infrastructure toward its realization. A preliminary prototype environment is being used by designers working on a variety of industry sponsored design projects. This testbed continues to inform and guide the development of NoteMail, MovieMail, and Xshare, as well other components of the next generation SHARE environment that will help distributed design teams work together more effectively.

this document should not be interpreted as representing the official policies, either expressed or implied, of the AAUW, AFOSR, ARPA, NSF, or the U.S. government.

Interoperability among a group of devices, applications, and services is typically predicated on those entities having some degree of prior knowledge of each another. In general, they must be written to understand the type of thing with which they will interact, including the details of communication as well as semantic knowledge such as when and how to communicate. This paper presents a case for "recombinant computing"---a set of common interaction patterns that leverage mobile code to allow rich interactions among computational entities with only limited a priori knowledge of one another. We have been experimenting with a particular embodiment of these ideas, which we call Speakeasy. It is designed to support ad hoc, end user configurations of hardware and software, and provides patterns for data exchange, user control, discovery of new services and devices, and contextual awareness.

This memorandum is a companion document to the current version of the RTP protocol specification draft-ietf-avt-rtp-*.ftxt,psg. It discusses protocol aspects of transporting real-time services (for example, voice or video) over packet-switched networks such as the Internet. It compares and evaluates design alternatives for a real-time transport protocol, providing rationales for the design decisions made for RTP. Also covered are issues of port assignment and multicast address allocation. An appendix provides a comprehensive glossary of terms related to multimedia conferencing. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author(s). INTERNET-DRAFT draft-ietf-avt-issues-02.ps May 9, 1994 Contents 1 Introduction 4 2 Goals 7 3 Services 9 3.1 Control and Data : : : : : : : : : : : : : : : : : : : : : : : : ...