From owner-ietf-822@dimacs.rutgers.edu Tue Oct 19 21:06:40 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11230; Tue, 19 Oct 93 20:37:09 EDT Received: from netcom6.netcom.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11226; Tue, 19 Oct 93 20:37:07 EDT Received: by netcom6.netcom.com (5.65/SMI-4.1/Netcom) id AA29649; Tue, 19 Oct 93 17:37:42 -0700 Message-Id: <9310200037.AA29649@netcom6.netcom.com> To: ietf-822@dimacs.rutgers.edu Subject: Application/Signature Date: Tue, 19 Oct 93 17:37:42 -0700 From: Greg Vaudreuil FYI- this new ID represents a mechanism for sending user contact information in MIME messages. It is intended as a replacement for the .signature files often appended to mail messages in the hope of creating an ad-hoc local directory of names. Greg V. ------- Forwarded Message Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-vaudreuil-mime-sig-00.txt Date: Tue, 19 Oct 93 10:49:57 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-Id: <9310191051.aa07398@IETF.CNRI.Reston.VA.US> - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application/Signature Author(s) : G. Vaudreuil Filename : draft-vaudreuil-mime-sig-00.txt Pages : 6 The memo defines a MIME content type for the exchange of sender contact information and user agent capability information beyond what is feasable in the RFC822 header. This exchange is generally accomplished by use of a signature trailer appended to the message. These signatures commonly contain address, phone, and email addressing. This document outlines a formalization and extension of the signature concept to provide a machine readable, internationally friendly form to exchange this information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-vaudreuil-mime-sig-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE draft-vaudreuil-mime-sig-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: 19931018165327.I-D@CNRI.Reston.VA.US FILE draft-vaudreuil-mime-sig-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-vaudreuil-mime-sig-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: 19931018165327.I-D@CNRI.Reston.VA.US - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From owner-ietf-822@dimacs.rutgers.edu Wed Oct 20 05:35:28 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17537; Wed, 20 Oct 93 04:59:37 EDT Received: from survis.surfnet.nl by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17533; Wed, 20 Oct 93 04:59:35 EDT Received: from localhost by survis.surfnet.nl with SMTP (PP) id <06217-0@survis.surfnet.nl>; Wed, 20 Oct 1993 09:59:16 +0100 To: imap@cac.washington.edu, ietf-822@dimacs.rutgers.edu, mime-mhs@surfnet.nl, ietf-nntp@net.bio.net, ietf-osi-ds@cs.ucl.ac.uk, telnet-ietf@cray.com, tn2370e@list.nih.gov, ietf-osi-x400ops@cs.wisc.edu, ietf-smtp@dimacs.rutgers.edu Subject: Announcement of Open Applications Area Meeting Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Wed, 20 Oct 93 09:59:15 +0100 From: "Erik Huizer (SURFnet BV)" Message-Id: <"survis.sur.219:20.09.93.08.59.18"@surfnet.nl> If you're in Houston, please come! Erik Special Applications and Services Meeting Announcement John Klensin APP Joyce Reynolds USV Erik Huizer APP This is to announce a combined Application Area and User Services Area session at the upcoming IETF. The session is meant to coordinate efforts in Application related groups in these two Areas of the IETF. The session takes place on Thursday 0930-1200. The session is split into two parts: Applications Area Directorate Open Meeting (apples) (0930-1045) Integrated Information Architecture (iia) (1045-1200) First part of the session: ========================== Open Applications Area Directorate meeting (apples) --------------------------------------------------- Within the IETF there are currently a lot of application related efforts going on. In the past year there has been some reshuffling of Applications related IETF activities: - Integration of OSI related work in Applications Area - Creation of WGs that are chartered in both the User Services AND the Applications Area. - Creation of the Service Applications Area The Applications Area Directorate and the IESG are trying to keep these in line and coordinated. However, it has been our experience that often enough participants in Application related WGs are not aware of similar or related work in other IETF WGs. As a result of this it happens sometimes that valuable input from one part of the IETF community to a certain spec, is only given at a very late stage, which is of course not beneficial to the result. To make people aware of what is going on in the IETF with regard to applications, this meeting intents to give an overview of ongoing work, and issues under discussion in the various WGs. The goal of this meeting is to assure the right level of expertise in each WG to cover all aspects of the work within that WG. We strongly encourage all people who participate in any Applications related WG, to attend this session. Second part of the session: =========================== Integrated Information Architecture (IIA) meeting in Houston When IESG created the IAFA, IIIR, NIR, URI, and WNILS working groups, it did so as components of an overall effort to develop a single coordinated Internet architectures for information naming, discovery, and retrieval system. The working groups involved have made rapid progress, but occasionally at the expense of coordination with each other, with other IETF WGs, and with existing practice outside IETF. It has seemed to the responsible area directors that coordinated efforts are even more important today as these efforts overlap and intertwine. This session is an open discussion of IIA issues with the chairs of the five WGs and the three area directors to determine what level of coordination of overlapping facilities is still appropriate and how to accomplish it. The results will include a progress report to IETF on the development of the integrated information service, as required by the charter statement. A copy of the original charter and IESG position statement follows for reference. - - --------------------- Integrated Information Architecture Many new networked services to identify, access, and retrieve information resources have sprung up in the last several years -- archie, WAIS, and Netfind, to name only three. Now, much as the Internet has tied many disparate networks together into an integrated system, the pressing problem is how to integrate these many new services into a single coordinated Internet information naming, discovery, and retrieval system. There are three vital areas of this integration effort that the IESG is interested in pursuing: 1) The identification, cataloging, and documentation of networked information services, new and old. 2) The standardization of descriptions and identification schemes for networked resources, and the distribution and implementation of these identifiers. 3) The integration and interoperability of the various new information services. To this end, the IESG is creating three new working groups: 1) Networked Information Retrieval (NIR) -- NIR will work on the first issue above by identifying, cataloging, and documenting networked information services. The result will be a published catalog of network information retrieval services. In addition, NIR will liase with other organizations working on this goal, such as RARE ISUS and CNI. 2) Uniform Resource Identifiers (URI) -- URI will concentrate on the second issue above, particularly on the standardization and implementation of identification schemes for networked resources. There will be two primary components in this effort: a Uniform Resource Locator (URL) which is a string which tells how to locate a document. The second part is a Universal Resource Serial Number, which is used to uniquely identify a resource, so that one can, for example tell if two documents with different file names are, in fact, the same. The standard identification scheme developed by URI will be used by NIR to define the standard resource formats. 3) Integration of Internet Information Resources (IIIR) -- IIIR will work on the third issue by developing technical specifications and documentation for a) interoperation between the various information services and b) the integration of new information services into the existing CIM (combined information mesh). After the specifications for interoperation have been completed, IIIR will examine the need for additional protocols necessary to further integrate the CIM, including gateway protocols, query routing protocols, and other mechanisms. In addition to the above named groups, the IETF wishes to facilitate the standardization of descriptions and data formats for various specific information services by chartering single-protocol working groups which will work on this standardization. Examples of such groups are the Internet Anonymous FTP Archive group (IAFA), which is working on standardization of anonymous FTP archives, and the new Whois Network Information Lookup Service (WNILS), which is working on standardization of services using the WHOIS protocol. The IESG considers these WGs to be components of a single coordinated IETF effort to create an integrated Internet information architecture. Therefore, the chairs and membership of each group will be active participants in the other groups. The overall coordination of this effort will be under the joint management of the Applications and User Services Area. Due to the importance of an Integrated Internet Information Service Architecture, the IESG requests the working group chairs and the Applications and User Services area directors to jointly expand this brief overview into a more fully fleshed out architectural statement, and to issue periodic progress reports describing how the integrated information service is developing. ----------- From owner-ietf-822@dimacs.rutgers.edu Thu Oct 21 17:20:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13337; Thu, 21 Oct 93 16:58:26 EDT Received: from MAGELLAN.TIS.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13333; Thu, 21 Oct 93 16:58:20 EDT Received: from [127.0.0.1] by magellan.TIS.COM id aa23882; 21 Oct 93 16:00 EDT Reply-To: James M Galvin To: pem-dev@tis.com, ietf-822@dimacs.rutgers.edu Subject: MIME-PEM Interaction Specification Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 21 Oct 1993 16:00:19 -0400 From: James M Galvin Message-Id: <9310211600.aa23882@magellan.TIS.COM> ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" We now have a moderately stable proposal for integration of MIME and PEM. It is included below and will also be submitted to the Internet Drafts directory. The main features of this spec are: - use of MIME's boundary and content transfer encoding mechanisms, - separation of encryption and signature processes - introduction of application/quoted-mime-entity to protect signed bodies (and use of the recently introduced multipart/headerset) - separation of enhancement from all transactions involving requests and replies for certificates and CRLs. It has taken a fair amount of time to work through the detailed interactions between the MIME and PEM cultures, but we think we've reached a very nice result. We believe it is premature to attempt to move this spec to Proposed Standard. It will take a while for the PEM and MIME communities to absorb and debate the details. Since quite a bit of the required mechanisms already exist in various implementations of PEM and MIME, we think it makes a lot of sense to whip up some experimental implementations to see how well these ideas work. We will do this, and we should have something ready for use by year's end. We'd like to include this on the PEM working group agenda for the Houston IETF meeting. Do folks wish to spend time on this? Steve Kent, is there time available? Thanks, Jim Galvin Sandy Murphy Steve Crocker ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Network Working Group Steve Crocker Internet Draft Ned Freed Jim Galvin Sandy Murphy Marshall Rose MIME-PEM Interaction Oct 15, 1993 1. 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 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 a "work in progress". 2. Abstract This memo defines a framework for interaction between MIME and PEM services. MIME, an acronym for "Multipurpose Internet Mail Extensions", defines the format of the contents of Internet mail messages and provides for multi-part textual and non-textual message bodies. PEM, an acronym for "Privacy Enhanced Mail", provides message encryption and message authentication/integrity services for Internet mail messages. draft MIME-PEM Interaction Oct 1993 3. Introduction An Internet electronic mail message consists of two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to MIME [2]. MIME does not provide encryption or authentication/integrity services. PEM [3-6] allows encryption and authentication/integrity enhancements to be applied to the contents of electronic mail messages but does not provide message structuring or type labelling facilities. This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. The resulting combined service provides encryption and authentication/integrity services for single-part and multi- part textual and non-textual messages. We refer to the authentication/integrity service as a signature. The services of encryption and signature are separated. This differs from the service provided by [3], in that the encryption privacy enhancement in [3] also computes a signature of the message. To take full advantage of the functionality provided by MIME, canonicalization and transfer encoding operations are removed from the privacy enhancement and left to the MIME agent. The content domain header, defined in [3], is not included, as its functionality is subsumed by MIME. Transmission of certificate and certificate revocation lists is separated from the privacy enhancement. The message types no longer need be mentioned in the headers, as the information they impart is contained in the content types. The requests and responses of [6] are provided for in new content types. This represents a departure in mechanism, although not in effect, from the procedures identified in [3]. Expires Jun, 1994 [Page 2] draft MIME-PEM Interaction Oct 1993 MIME-PEM interaction is provided for by defining six new MIME content types: application/pem-keys, application/pem- signature, application/pem-encrypted, application/quoted-mime- entity, application/pem-request and application/certdata. The MIME-PEM interaction also uses another new MIME type, multipart/headerset, proposed by David Crocker. The relationship between MIME and PEM is described in terms of two functions, message composition and message delivery. The new content types have two different purposes. The first four types (application/pem-keys, application/pem-signature, application/pem-encrypted and application/quoted-mime-entity) are used to transmit and receive privacy enhanced messages and are always encapsulated in a multipart/headerset body part. The last two types (application/pem-request and application/ certdata) are used to transmit requests for certificate operations (retrieval, certification, revocation lists retrieval, etc.) and the responses to those requests. These two content types are independent body parts, not required to be encapsulated in any other body part. The two groups of content types are discussed in the two sections following. 4. Definition of new enhancement Content Types 4.1. Multipart/headerset Content Type Definition (1) MIME type name: multipart (2) MIME subtype name: headerset (3) Required parameters: boundary (4) Optional parameters: none (5) Encoding considerations: Either 7bit, 8bit, or binary encoding may be used, depending on the nested part encodings and transport limitations. (6) Security Considerations: see [3] Expires Jun, 1994 [Page 3] draft MIME-PEM Interaction Oct 1993 The headerset subtype of multipart always contains at least two body parts, where the first body part gives instructions in some way for the processing of all the body parts. In this use of the headerset subtype, there are always two body parts. The first part describes the privacy enhancement which was applied to the second body part. The first part's content type is application/pem-signature or application/pem-keys. The second body part contains a body part which contains the privacy-enhanced content. The second part's content type is either application/pem-encrypted, if the requested privacy enhancement is encryption, or application/quoted-mime-entity, if the requested privacy enhancement is signature. The syntax and semantics of the boundary parameter is defined in [2]. 4.2. Application/pem-keys Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-keys (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production for , which differs from the in [3] in that neither the nor the fields conveying certificates or related exclusively to signature are a part of the production. (The certificate fields appear in the application/certdata content type, see Section 5.2). The field is also eliminated. The field is replaced by the field, as the message types included in are imparted by the content type name of the body part. The productions , , Expires Jun, 1994 [Page 4] draft MIME-PEM Interaction Oct 1993 , and are as defined in section 9 of [3]. ::= (1*( *)) ; symmetric case /((1*) *()) ; asymmetric case ::= "Version" ":" "5" CRLF ::= [] ;asymmetric / [] ;symmetric This content type must be used as the first part of a multipart/headerset content type. It may not be used in any other context. 4.3. Application/pem-signature Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-signature (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production for , which differs from the in [3] in that neither the nor the fields conveying certificates or related exclusively to encryption are a part of the production. (The certificate fields appear in the application/certdata content type, see Section 5.2). The field is also eliminated. The field is replaced by the field, as the message types included in are imparted by the content type name of the body part. The productions , , Expires Jun, 1994 [Page 5] draft MIME-PEM Interaction Oct 1993 , and are as defined in section 9 of [3]. ::= (1*( *)) ; symmetric case /((1*) *()) ; asymmetric case ::= "Version" ":" "5" CRLF ::= [] ;asymmetric / [] ;symmetric This content type must be used as the first part of a multipart/headerset content type. It may not be used in any other context. 4.4. Application/pem-encrypted Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-encrypted (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: The encryption will produce binary data and may need to be encoded for transport. Any transport-compatible encoding capable of accommodating binary data may be used. A base64 encoding will be sufficient for all transport systems. (6) Security Considerations: see [3] The content of the application/pem-encrypted is an encrypted valid MIME object. Because it is encrypted, the canonical form of this content type is any arbitrary data. This content type must be used as the second part of a multipart/headerset content type. It may not be used in any Expires Jan, 1994 [Page 6] draft MIME-PEM Interaction Jul 1993 other context. 4.5. Application/quoted-mime-entity Content Type Definition (1) MIME type name: application (2) MIME subtype name: quoted-mime-entity (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: If the quoted mime body part has a quoted printable, 7bit, or base64 transfer encoding indicated, the transfer encoding of this body part should be 7bit to avoid nested encodings. Otherwise, any transport-compatible encoding capable of accommodating the content type of the quoted mime body part may be used. (6) Security Considerations: see [3] The application/quoted-mime-entity content is constrained to be a valid MIME object. The content of that body part must be in the canonical form for its content type. This content type must be used as the second part of a multipart/headerset content type. It may be used in any other context, as well. The application/quoted-mime-entity content type may on first inspection appear to be superfluous since the content it contains is itself constrained to be a valid MIME object. However, the use of application/quoted-mime-entity serves a vital function: it protects the inner MIME object from any changes that might be performed by messaging gateways. Such changes frequently disrupt header and boundary information, which in turn would lead to integrity check failures. Expires Jun, 1994 [Page 7] draft MIME-PEM Interaction Oct 1993 The use of application/quoted-mime-entity ensures that if a gateway is compelled to make encoding changes it will do so on the application/quoted-mime-entity object as a whole. Such encoding changes, if done properly, will leave the application/quoted-mime-entity content entirely intact. The application/quoted-mime-entity type may be generally useful outside PEM, as well. We intend for this to be a type that could be used anywhere in a MIME object and not restricted to PEM. 5. Definition of new certificate Content Types 5.1. Application/pem-request Content Type Definition (1) MIME type name: application (2) MIME subtype name: pem-request (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production. ::= ::= "Version" ":" "5" CRLF ( / / ) ::= "Subject" ":" CRLF ::= "Issuer" ":" CRLF ::= "Certification" ":" CRLF The purpose of this body part is to transmit a request. The request can be "Certification", which requests certification of a self-signed certificate, or "Subject", which requests the Expires Jun, 1994 [Page 8] draft MIME-PEM Interaction Oct 1993 certificate chain corresponding to a subject identified by a distinguished name, or "Issuer", which requests the revocation list chain issued by an issuer identified by a distinguished name. The "Subject" and "Issuer" fields each contain a value of type Name, encoded according to the Basic Encoding Rules, then in ASCII, as for the "Originator-ID-Asymmetric" field of [3]. In each case, the response can be transmitted in an application/certdata content type. This type is intended to provide for the requests described in [6]. The key certification request and CRL-retrieval request are provided for directly. The CRL-storage request is provided for by transmitting the CRL's to be stored in an application/certdata content type. 5.2. Application/certdata Content Type Definition (1) MIME type name: application (2) MIME subtype name: certdata (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: 7bit is always sufficient. (6) Security Considerations: see [3] The canonical form of this content type corresponds to the following production built on top of the definitions in section 9 of [3]. ::= / ::= ( *([])) ::= 1*([ ::= "Certificate" ":" CRLF ::= "Version" ":" "5" CRLF Expires Jun, 1994 [Page 9] draft MIME-PEM Interaction Oct 1993 This content type is used to transfer certificate or certificate revocation list information. This information is entirely independent of any particular enhanced message. (Note that the converse is not true: the validity of an enhanced message cannot be determined without the proper certificates or current CRL information.) As such, the application/pem- certdata content type is an independent body part. It is not used in a multipart/headerset context containing PEM enhanced messages. The production contains one certificate chain. Each certificate chain starts with a certificate and continues with the certificates of subsequent issuers. Each issuer listed is presumed to have issued the preceding certificate. For each issuer, a CRL may be supplied. A CRL in the chain belongs to the immediately following issuer. Therefore, it potentially contains the immediately preceding certificate. The production contains one certificate revocation list chain. The CRLs in the chain begin with a requested CRL and continue with the CRLs of subsequent issuers. The issuer of each CRL is presumed to have issued a certificate for the issuer of the preceding CRL. For each CRL, the issuer's certificate may be supplied. A certificate in the chain must belong to the issuer of the immediately preceding CRL. The relationship between a certificate and an immediately preceding CRL is the same in both cases. In a the crl's are optional. In a , the certificates are optional. 6. Message Composition When a user composes a message, it is the responsibility of the user agent to construct a valid MIME message. In particular, Content-Type: and Content-Transfer-Encoding: headers should be used wherever they are appropriate. This allows the receiving user agent to unambiguously interpret the Expires Jun, 1994 [Page 10] draft MIME-PEM Interaction Oct 1993 message body and process it accordingly. Each block of content headers associated with either an RFC822 or with a MIME represents a logical place where privacy enhancement can be requested. A privacy enhancement request associated with a particular or content is taken to apply to the entire content; it is not possible to privacy-enhance only a portion of a body part. The mechanism used to communicate privacy enhancement requests to the pre-submission processor described below is strictly a local implementation issue. However, the interface between the message composer and pre-submission processing MUST be trustworthy, since the message composer relies on pre- submission processing to either perform the requested privacy enhancement operation or return an error. Regardless of the mechanism chosen, great care should be taken to safeguard against both the release of information that has not received the requested type of privacy enhancement as well as tampering with the enhancement request itself. 6.1. Pre-Submission Algorithm The user agent first composes a MIME-compliant message and then applies this algorithm: (1) If the content at this (initially top) level has NOT been selected for privacy enhancement, the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content. (2) If the content at this level has been selected for privacy enhancement, then the content, including its headers, constitutes the object that receives privacy enhancement. The headers at a minimum will include a Content-Type header, either explicit or implicit. The object will eventually be replaced with the multipart/ Expires Jun, 1994 [Page 11] draft MIME-PEM Interaction Oct 1993 headerset content that is produced by the privacy enhancement operation. (3) The content of the object must be transformed from local form to its MIME binary canonical form. Also, if the requested privacy enhancement is signature, and if Content-Transfer-Encoding: headers were present in the headers of the object, the content encoding is reversed, leaving only 7BIT, 8BIT, and BINARY as possible encodings for all body parts. This is done so that any artifacts introduced by encoding are removed and consistent integrity checks will be generated. (4) Once an object in binary canonical form has been produced the selected privacy enhancement is performed. The privacy enhancement produces two data streams: the privacy enhanced object and a control stream comprised of a set of headers as defined in the or productions. (5) A new body part is then constructed, of content type multipart/headerset. The body part contains two body parts, whose content depends on the privacy enhancement requested. (a) If the requested privacy enhancement is encryption, then the first body part within the multipart/ headerset is labelled with a content type of application/pem-keys and contains the control stream produced by the privacy enhancement. The second body part within the multipart/headerset is labelled with a content type application/pem- encrypted, and contains the privacy enhanced object produced by the privacy enhancement. An appropriate transfer encoding is also applied to the content and a corresponding Content-Transfer-Encoding: header is added to the application/pem-encrypted body part. Base64 encoding is recommended in the case of encryption privacy enhancement in order to be backwards-compatible with the original PEM conventions. (b) If the requested privacy enhancement is signature, then the first body part within the multipart/ headerset is labelled with a content type of Expires Jun, 1994 [Page 12] draft MIME-PEM Interaction Oct 1993 application/pem-signature and contains the control stream produced by the privacy enhancement. The second body part within the multipart/headerset is labelled with a content type application/quoted- mime-entity, and contains the privacy enhanced object produced by the privacy enhancement. An appropriate transfer encoding is also applied to the content and a corresponding Content-Transfer-Encoding: header is added to the application/quoted-mime-entity bodypart. This multipart/headerset content replaces the original object. 7. Post-Delivery Algorithm When a user receives a message containing a multipart/ headerset content, the user agent may transform the content back into its original form prior to privacy-enhancement. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm. When the original content is reconstituted into its MIME binary canonical form, it may use octet values outside of the US-ASCII repertoire and may contain body parts without line breaks. If the user agent replaces the multipart/headerset content with the original content, then it must select appropriate Content-Transfer-Encodings for each body part and add corresponding Content-Transfer-Encoding: headers. Upon successful completion of the post-delivery algorithm for each content, the type of privacy enhancement that was in effect for that content must be communicated to the user. The mechanism used to do this is a local implementation issue. As with requests for privacy enhancement to the pre-submission algorithm, the path between post-delivery processing and actual display of the message must be a trusted one, lest a message be presented that purports to have undergone some form of privacy enhancement it did not in fact receive. 8. Examples For example, suppose the following body part was selected for Expires Jun, 1994 [Page 13] draft MIME-PEM Interaction Oct 1993 privacy enhancement: Content-Type: message/rfc822 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! After applying pre-submission algorithm with a request that signature privacy enhancement be applied to the body part, the body part submitted for delivery would appear as: Content-Type: multipart/headerset; boundary="Privacy Boundary" --Privacy Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary Content-Type: application/quoted-mime-entity Content-Type: message/rfc822 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --Privacy Boundary-- After applying the post-delivery algorithm, the resulting body part would once again appear as: Expires Jun, 1994 [Page 14] draft MIME-PEM Interaction Oct 1993 Content-Type: message/rfc822 To: ned@innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! The body part need not be ascii text. For example, the following audio body part could be privacy enhanced: Content-Type: audio Content-Transfer-Encoding: base64 JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj producing the following body part: Content-Type: multipart/headerset; boundary="Privacy Boundary" --Privacy Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary Content-Type: application/quoted-mime-entity Content-Transfer-Encoding: 7bit Content-Type: audio Content-Transfer-Encoding: base64 JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj Expires Jun, 1994 [Page 15] draft MIME-PEM Interaction Jul 1993 --Privacy Boundary-- The following privacy-enhanced message illustrates how an enhanced body part can itself receive enhancement. Date: Mon, 29 Mar 93 13:57:08 -0500 From: Greg Vaudreuil To: Marshall Rose Subject: Forwarded integrity Message MIME-Version: 1.0 Content-Type: multipart/headerset; boundary="Privacy Boundary" --Privacy Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Privacy Boundary Content-Type: application/quoted-mime-entity Content-Type: multipart/mixed; boundary="Middle Boundary" --Middle boundary Content-Type: text/plain; charset=us-ascii The enclosed message was integrity enhanced. Greg V. --Middle Boundary Content-Type: multipart/headerset; boundary="Forwarded Message" --Forwarded Message Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 Expires Jun, 1994 [Page 16] draft MIME-PEM Interaction Jul 1993 MIC-Info: RSA-MD5,RSA,... --Forwarded Message Content-Type: application/quoted-mime-entity Content-Type: message/RFC822 Date: Mon, 29 Mar 93 13:53:02 -0500 From: Ned Freed To: Greg Vaudreuil Subject: Minimal PEM Message This is a signed message using MIME-PEM. Greg V. --Forwarded Message-- --Middle Boundary-- --Privacy Boundary-- The following privacy-enhanced body part illustrates the use of encryption and the application/pem-encrypted content type. Content-Type: multipart/headerset; boundary="PEM Boundary" --PEM Boundary Content-Type: application/pem-keys Version: 5 DEK-Info: DES-CBC,4C776432D61A9829 Originator-ID-Asymmetric: ...,09 Key-Info: RSA,... --PEM Boundary Content-Type: application/pem-encrypted Content-Transfer-Encoding: base64 8R/EVhZy7OU= --PEM Boundary-- Expires Jun, 1994 [Page 17] draft MIME-PEM Interaction Jul 1993 If it was desired to produce a signed and encrypted body part, the signature would be done first, producing: Content-Type: multipart/headerset; boundary="Sign Boundary" --Sign Boundary Content-Type: application/pem-signature Version: 5 Originator-ID-Asymmetric: ...,09 MIC-Info: RSA-MD5,RSA,... --Sign Boundary Content-Type: application/quoted-mime-entity Content-Type: message/RFC822 To: Ned Freed Subject: Strongly Protected Message This will be signed and encrypted. Let the bad guys do their worst! Jim --Sign Boundary-- and then it would be encrypted, producing: Content-Type: multipart/headerset; boundary="Enc Boundary" --Enc Boundary Content-Type: application/pem-keys Version: 5 DEK-Info: DES-CBC,4C776432D61A9829 Originator-ID-Asymmetric: ...,09 Key-Info: RSA,... --Enc Boundary Expires Jun, 1994 [Page 18] draft MIME-PEM Interaction Jul 1993 Content-Type: application/pem-encrypted Content-Transfer-Encoding: base64 9S/FWjAz8P=V --Enc Boundary-- where the encrypted contents, 9S/FWjAz8P=V, are the encryption of the first multipart/headerset. 9. Observations The use of the pre-submission and post-delivery algorithms to combine PEM and MIME capabilities exhibit several properties: (1) It allows privacy-enhancement of an arbitrary content, not just an entire RFC 822 message. (2) For a multipart or message content, it allows the user to decide whether the structure of the content should receive what sort of privacy-enhancement. (3) It provides for messages containing several privacy enhanced contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components. The use of a MIME-capable user agent makes complex nesting of enhanced message body parts much easier. For example, the user can separately sign and encrypt a message. This motivates a complete separation of the confidentiality security service from the authentication/message integrity security service. That is, different keys could be used for the different services and protected separately. In the asymmetric case, this means an employee's company could be given access to the (private) decryption key, granting the company the ability to decrypt messages addressed to the employee in emergencies, without also granting the company the ability to sign messages as the employee. Expires Jun, 1994 [Page 19] draft MIME-PEM Interaction Jul 1993 The use of two private keys requires the ability to maintain multiple certificates for each user. 10. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. 11. References [1] D.H. Crocker, Standard for the Format of ARPA Internet Text Messages, RFC 822, August, 1982. [2] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions, RFC 1341, June 1992. [3] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures, RFC 1421, DEC, February 1993. [4] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management, RFC 1422, BBN, February 1993. [5] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers, RFC 1423, TIS, February 1993. [6] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services, RFC 1424, RSA Laboratories, February 1993. [7] R. Braden, Editor, Requirements for Internet Hosts -- Application and Support, RFC 1123, October 1989. 12. Author Addresses Steve Crocker Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 email: crocker@tis.com Expires Jun, 1994 [Page 20] draft MIME-PEM Interaction Jul 1993 Ned Freed Innosoft International, Inc. 250 West First Street, Suite 240 Claremont, CA 91711 USA Tel: +1 909 624 7907 Fax: +1 909 621 5319 email: ned@innosoft.com Jim Galvin Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 email: galvin@tis.com Sandra Murphy Trusted Information Systems 3060 Washington Road Glenwood, MD 21738 email: murphy@tis.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 Tel: +1 415 968 1052 Fax: +1 415 968 2510 email: mrose@dbc.mtview.ca.us Expires Jun, 1994 [Page 21] ------- =_aaaaaaaaaa0-- From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 00:36:24 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07729; Mon, 25 Oct 93 00:13:55 EDT Received: from WILMA.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07725; Mon, 25 Oct 93 00:13:53 EDT Received: by wilma.cs.utk.edu (5.61+IDA+UTK-930922/2.8c-UTK) id AA19787; Mon, 25 Oct 93 00:08:09 -0400 Date: Mon, 25 Oct 93 00:08:09 -0400 From: moore@cs.utk.edu Message-Id: <9310250408.AA19787@wilma.cs.utk.edu> To: ietf-822@dimacs.rutgers.edu Subject: yet another way to indicate related MIME body parts Cc: moore@cs.utk.edu I've been working on a cleaner way to indicate relations among MIME body parts. I'd like to throw this one in as another strawman. Whatever we choose, I'd much rather see a generalized mechanism for composite content-types that need to reference one another, than having separate multipart contents for each composite type. NOTE: Since this is going out to the whole ietf-822 list, only the first abstract and introduction of the draft is below. The remainder can be had by ftp from cs.utk.edu:/pub/MIME/draft-moore-mime-references-00.txt and eventually from the internet-drafts repositories. This proposal is similar to several other proposals that have been floated here. It tries to define a general mechanism by which one MIME content can reference another one, as long as both are contained within the same multipart/references construct. The downside is that the programs that display (or more generally, "present") MIME contents have to know how to access those contents from within. An appendix to this draft describes a fairly system-independent mechanism by which this might be accomplished. Keith -------- Network Working Group Keith Moore Internet Draft University of Tennessee 24 October 1993 Multipart/References MIME Content-Type draft-moore-mime-references-00.txt 1. Status of this Memo [ this is boilerplate ] 2. Abstract This memo defines a new MIME content-type "multipart/references", which can be used to denote a set of MIME contents, of which any one may reference the others by its MIME content-id. This mechanism may be used by presentation languages that wish to be able to reference MIME objects, or by other applications (file transfer, authentication, delivery reports) which need to supply related information about another MIME object. 3. Introduction Several new MIME [1] -based applications are being developed which require data that is best represented (within a MIME message) as multiple MIME body parts. Frequently, such applications simply need to "embellish" or provide additional information about one or more other objects, which themselves are naturally represented as MIME body parts. Examples of such applications include the following: + File transfer. When using MIME to transfer a file, it is useful to represent the file being transferred as a MIME body part (with appropriate MIME content-type labelling), and provide additional information (ownership, creation date, permissions, icon, or data specific to a particular system) in a separate body part. A MIME mail reader could present the contents of the file being transferred in addition to offering to store the file on the recipient's file system. K. Moore Expires 24 April 1994 [Page 1] Multipart/References 24 October 1993 + Authentication. A separate body part could be used as a certificate of authorship and integrity check, using protocols such as PEM [2,3,4,5]. + Delivery and receipt notifications. A delivery status notification (or receipt notification) may include both the original message, and a separate body part indicating why the delivery of the message failed. The mechanism defined in this memo could be used to illustrate the relationship between the two. + Hypertext systems. It may be desirable to transmit a set of hypertext documents which reference one another, in a single MIME message. + Presentation languages. Since MIME says little about how the objects it carries are to be presented, this extension may be used by presentation languages that wish to reference other MIME objects. Although MIME [5] defines a content-id header which can be used for this purpose, it provides no mechanism by which one body part can reference another. Neither does it provide a mechanism to indicate whether a particular body part should be presented by a mail reader, stored in a file (as in an attachment), or whether the body part is intended to be referenced by another body part. This memo thus defines: + a "multipart/references" content-type to be used to indicate a set of body parts that may reference one another. + a new "internal" access-type for the message/external-body content- type, which instructs the mail reader to present another body part contained within the same multipart/references content. (This is intended to be used within multipart/alternative, as a fallback for when better presentation languages are not supported.) --------------- [ if you're still interested, get the whole document ] From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 11:08:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11512; Mon, 25 Oct 93 10:12:12 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11508; Mon, 25 Oct 93 10:12:11 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA11861; Mon, 25 Oct 93 07:12:10 -0700 Message-Id: <9310251412.AA11861@Mordor.Stanford.EDU> To: ietf-822@dimacs.rutgers.edu Subject: Query on a nit: Application vs. Text conten-type Contact: phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Mon, 25 Oct 93 07:12:10 -0700 From: Dave Crocker X-Mts: smtp I notice that the tendency with nearly all of the specifications produced in recent months is to class a new subtype under Content-type:Application. Some of these involve data that are text (usually standard, simple ASCII) and would be moderately (or even highly) understandable to a human if the content were presented to their screen. I wonder whether such data would not be better classed under Content-type: Text? Not a big deal? Probably not. However under Content-type:Application typical mail readers will take the most conservative stance, restricting all handling of the data to processing it through a separate program; hence if they don't know the sub-type, they won't process it. Under Content-type:text, minimal handling, by displaying to the screen, would seem entirely reasonable. Do folks care about this? Any suggestion for language to give guidance to Mime body-part spec writers? Dave From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 13:06:40 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12853; Mon, 25 Oct 93 12:29:35 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12849; Mon, 25 Oct 93 12:29:33 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA12944 (5.67a/IDA-1.5 for ); Mon, 25 Oct 1993 11:29:09 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA10371 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Mon, 25 Oct 1993 11:30:41 -0500 Message-Id: <199310251630.AA10371@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Oct 1993 11:30:08 -0500 To: Dave Crocker , ietf-822@dimacs.rutgers.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: Query on a nit: Application vs. Text conten-type At 7:12 AM 10/25/93 -0700, Dave Crocker wrote: >Do folks care about this? Any suggestion for language to give guidance >to Mime body-part spec writers? - We have to worry about newline conversion. Encoders and decoders need to know whether line breaks should be mapped to CRLF and vice-versa. Anyone registering a text subtype should specify this. (Anyone registering any subtype should specify it, I think.) - I know of one WP that stores its text largely as plain text, but in random chunks of no particular size or order. Is it worthwhile to call this a text subtype? If not, then we have a guideline about presenting text in order. :-) -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 14:40:06 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17211; Mon, 25 Oct 93 13:39:46 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17207; Mon, 25 Oct 93 13:39:44 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H49TQTP6IO8WVZ4V@INNOSOFT.COM>; Mon, 25 Oct 1993 10:39:26 PST Date: Mon, 25 Oct 1993 10:33:16 -0800 (PST) From: Ned Freed Subject: Re: Query on a nit: Application vs. Text conten-type In-Reply-To: Your message dated "Mon, 25 Oct 1993 07:12:10 -0700" <9310251412.AA11861@Mordor.Stanford.EDU> To: Dave Crocker Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H4IYWMX5FQ8WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > I notice that the tendency with nearly all of the specifications > produced in recent months is to class a new subtype under > Content-type:Application. Some of these involve data that are > text (usually standard, simple ASCII) and would be moderately (or > even highly) understandable to a human if the content were > presented to their screen. If this is the case the types should have been registered under text. The minimal MIME conformance guidelines make this quite clear, I believe. > I wonder whether such data would not be better classed under > Content-type: Text? It is a judgement call the registrar of the type has to make. However, I don't know what subtypes you are referring to. Would you care to elaborate? > Not a big deal? Probably not. Actually, it can be a very big deal. Most agents will offer to show an unencoded application/whatever as text, but many won't allow it if an encoding has been applied. (For one thing, the EOL sequence in this case is entirely arbitrary.) A subtype of text doesn't have this limitation. > However under Content-type:Application typical mail readers will > take the most conservative stance, restricting all handling of the > data to processing it through a separate program; hence if they don't > know the sub-type, they won't process it. Under Content-type:text, > minimal handling, by displaying to the screen, would seem entirely > reasonable. It is not only reasonable, it is required. See Appendix A. > Do folks care about this? Any suggestion for language to give guidance > to Mime body-part spec writers? The necessary language is already in place. You can lead a horse to water but... Ned From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 15:07:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17702; Mon, 25 Oct 93 14:12:45 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17698; Mon, 25 Oct 93 14:12:44 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA14235; Mon, 25 Oct 93 11:12:34 -0700 Message-Id: <9310251812.AA14235@Mordor.Stanford.EDU> To: Ned Freed Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Query on a nit: Application vs. Text conten-type Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 25 Oct 93 10:33:16 -0800. <01H4IYWMX5FQ8WVZ4V@INNOSOFT.COM> Date: Mon, 25 Oct 93 11:12:34 -0700 From: Dave Crocker X-Mts: smtp Ned, ---- Included message: > I wonder whether such data would not be better classed under > Content-type: Text? It is a judgement call the registrar of the type has to make. However, I don't know what subtypes you are referring to. Would you care to elaborate? Well, STIF is not a distinct type, but PCI uses STIF and I chose to class it as Content-type:Text on the theory that humans ought to be quite comforable reading the stuff. (That was, after all, a design goal for STIF.) The spec for Signature uses Application. Those are the two that pop to mind immediatley. If I foraged, I'd probably come up with more. Lots of conversations have also triggered this question. d/ From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 16:39:53 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18807; Mon, 25 Oct 93 15:37:02 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18803; Mon, 25 Oct 93 15:37:01 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 25 Oct 93 15:35:51 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for moore@cs.utk.edu; Mon, 25 Oct 93 15:36:42 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.bellcore.com.sun4.41 via MS.5.6.guppylake.bellcore.com.sun4_41; Mon, 25 Oct 1993 15:36:41 -0400 (EDT) Message-Id: <0gn2f9m0M2UDNPVhQ7@thumper.bellcore.com> Date: Mon, 25 Oct 1993 15:36:41 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: yet another way to indicate related MIME body parts Cc: moore@cs.utk.edu In-Reply-To: <9310250408.AA19787@wilma.cs.utk.edu> References: <9310250408.AA19787@wilma.cs.utk.edu> I've read Keith's draft, and I'm surprised at how much I like it. I think that Keith has added to the value of this idea significantly with the "start" parameter and the internal reference type. I think this is the first draft of this type that really lets you do some things more easily than with a new multipart/foobar type for each application. I particularly like having the "start" parameter in the enclosing multipart header, because it gives a general-purpose MIME parser (e.g. metamail) a way to tell what program to call on the inner stuff, which unparameterized types like "multipart/header-set" really didn't offer. One technical question: What should a MIME-reader do if it implements multipart/related, but doesn't recognize the type of data in the "start" object? You obviously prefer to avoid this case by using multipart/alternative, but it will inevitably happen! I'm still a bit skeptical about the appendix. That's a lot of work to go through for inventing file names. A possibly simpler approach would be to pass the inner program the name of a directory file, which would contain a line for each body part, of the form filename Sounds at least as good, and a LOT easier to implement..... Anyway, I really like this draft. Is there any chance that the authors of multipart/header-set, multipart/related, multipart/reference, multipart/appledouble, and multipart/enabled-mail could all get together and refine this into something we can all use? -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 18:09:26 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19852; Mon, 25 Oct 93 17:16:05 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19848; Mon, 25 Oct 93 17:16:03 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA17024; Mon, 25 Oct 93 14:15:59 -0700 Message-Id: <9310252115.AA17024@Mordor.Stanford.EDU> To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: yet another way to indicate related MIME body parts Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 25 Oct 93 15:36:41 -0400. <0gn2f9m0M2UDNPVhQ7@thumper.bellcore.com> Date: Mon, 25 Oct 93 14:15:59 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: Is there any chance that the authors of multipart/header-set, multipart/related, multipart/reference, multipart/appledouble, and multipart/enabled-mail could all get together and refine this into something we can all use? (there are one or two other specs coming down the pike that need/use a construct of this category, too.) In answer to your question, I would be surprised if we could not resolve this down to one spec. I just hope I get the time to read Keith's today... d/ From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 18:37:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19928; Mon, 25 Oct 93 17:34:06 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19924; Mon, 25 Oct 93 17:34:05 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA11851; Mon, 25 Oct 93 17:33:56 -0400 Message-Id: <9310252133.AA11851@thud.cs.utk.edu> From: Keith Moore To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Mon, 25 Oct 1993 15:36:41 EDT." <0gn2f9m0M2UDNPVhQ7@thumper.bellcore.com> Date: Mon, 25 Oct 1993 17:33:54 -0400 Sender: moore@cs.utk.edu > I've read Keith's draft, and I'm surprised at how much I like it. I > think that Keith has added to the value of this idea significantly with > the "start" parameter and the internal reference type. I think this is > the first draft of this type that really lets you do some things more > easily than with a new multipart/foobar type for each application. I > particularly like having the "start" parameter in the enclosing > multipart header, because it gives a general-purpose MIME parser (e.g. > metamail) a way to tell what program to call on the inner stuff, which > unparameterized types like "multipart/header-set" really didn't offer. Actually, I'm not sure I understand the difference between having a start parameter that can indicate any body part, and always having "start" be the first body part (as in header-set). In either case the mail reader has to look at the headers for that body part before processing the mail. (but either one of these should be easier to deal with than multipart/foo) > One technical question: What should a MIME-reader do if it implements > multipart/related, but doesn't recognize the type of data in the "start" > object? You obviously prefer to avoid this case by using > multipart/alternative, but it will inevitably happen! I think it's just like when a mail reader doesn't recognize any other object -- it refuses to present it, and maybe offers to save it in a file. In this case the object saved in a file would presumably be the entire multipart/references object. If the "start" object can't be displayed, sometimes it makes sense to have the mail reader present the individual objects, sometimes not. If the sender wants the fallback behavior he should use multipart/alternative for the start object. > I'm still a bit skeptical about the appendix. That's a lot of work to > go through for inventing file names. A possibly simpler approach would > be to pass the inner program the name of a directory file, which would > contain a line for each body part, of the form > > filename > > Sounds at least as good, and a LOT easier to implement..... Perhaps. But you at least have to decide how to pass the name of the "directory file" to the inner program. command-line? standard-input? (I suppose this could be metamail-configurable.) > Anyway, I really like this draft. Is there any chance that the authors > of multipart/header-set, multipart/related, multipart/reference, > multipart/appledouble, and multipart/enabled-mail could all get together > and refine this into something we can all use? -- Nathaniel I hope so! Keith From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 19:08:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20211; Mon, 25 Oct 93 18:04:52 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20207; Mon, 25 Oct 93 18:04:50 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA24217 (5.67a/IDA-1.5 for ); Mon, 25 Oct 1993 17:04:24 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA10861 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Mon, 25 Oct 1993 17:05:56 -0500 Message-Id: <199310252205.AA10861@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Oct 1993 17:05:21 -0500 To: ietf-822@dimacs.rutgers.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: yet another way to indicate related MIME body parts > When presenting a multipart/references body part, the mail reader >first scans all of the components contained within. Then it presents This is very onerous in certain environments, where spool space is limited or disk performance is suspect. In transferring an AppleDouble file, I might wind up writing each part of the file, and then copying one part into another when the message finally got around to telling me what I was dealing with. > Required parameters: start What is the improvement of being able to designate some later part as the master part, rather than just using the first one? >Troost's "content-disposition" documents. No provision is made for the filename parameter of content-disposition. This leaves us with no accepted way to hint at a filename, since 1521 deprecates name=. That's easily remedied by un-deprecating it, I suppose. How do we specify that a body part should really be written to a file, not displayed to the user? content-disposition allowed that; I don't see how this does, unless the "start" part (could I nominate "control" instead of "start"?) is known to the mailer. It seems to me that learning new types is "hard", whereas simply looking for a fixed header value is "easy". >multipart/references ; start=D { > A: [body-part-A] > B: [body-part-B] > C: [body-part-C] > D: multipart/alternative { > application/foo (which references A, B, and C internally) > multipart/mixed > message/external-body; access-type=internal; content-id=A > message/external-body; access-type=internal; content-id=B > message/external-body; access-type=internal; content-id=C > } >} Nit: in part D, shouldn't the application/foo come last, as the "most preferred" part? How would I represent a file in AppleDouble using this scheme? Assuming a benign (instead of pathological) ordering, I guess something like: multipart/references ; start=A { A: application/appledouble B: application/applefile C: image/gif } So I need "appledouble" (which describes the start section), and "applefile" to do what I need to do. You will ALWAYS need to define at least two types for each composite type; one that describes what sort of composite type it is and how the parts fit together, and one for the "extra" or "optional" information. Or do you have this in mind: multipart/references ; start=A { A: application/appledouble B: application/octet-stream C: image/gif } Here the identity of part B is totally encapsulated in part A. This avoids the need to register a type for B, but I'm uneasy about having the part itself unlabelled. How do I represent the fact that some of the data parts are optional, and that the mailer shouldn't bother the user if it doesn't understand them? Must I ALWAYS make the start part be multipart/alternative? multipart/references ; start=A { A: multipart/alternative { message/external-body; access-type=internal; content-id=C application/appledouble } B: application/octet-stream C: image/gif } Under header-set, I accomplish what I need with far less mechanism: multipart/header-set { application/applefile image/gif } This seems to me a lot easier to deal with, at least for my problem. I can see that references might work better for other problems. -- Steve Dorner, Qualcomm Inc. Sometimes it's easier to let your cockatoo eat your shoes than to hear him scream. From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 20:37:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21096; Mon, 25 Oct 93 20:01:53 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21091; Mon, 25 Oct 93 20:01:51 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18690; Mon, 25 Oct 93 17:01:45 -0700 Message-Id: <9310260001.AA18690@Mordor.Stanford.EDU> To: Keith Moore Cc: Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 25 Oct 93 17:33:54 -0400. <9310252133.AA11851@thud.cs.utk.edu> Date: Mon, 25 Oct 93 17:01:45 -0700 From: Dave Crocker X-Mts: smtp Some points for debate <> ---- Included message: Actually, I'm not sure I understand the difference between having a start parameter that can indicate any body part, and always having "start" be the first body part (as in header-set). Only the most obvious distinction comes to mind. Header-set has an extremely small look-ahead requirement. Since the start parameter can be on *any* of the body parts and the length of each part is arbitrary, look-ahead can be painful. Dave From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 21:17:47 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25324; Mon, 25 Oct 93 20:36:03 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25320; Mon, 25 Oct 93 20:36:02 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 25 Oct 93 20:35:58 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 25 Oct 93 20:36:49 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.bellcore.com.sun4.41 via MS.5.6.guppylake.bellcore.com.sun4_41; Mon, 25 Oct 1993 20:36:48 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 20:36:48 -0400 (EDT) From: Nathaniel Borenstein To: Keith Moore Subject: Re: yet another way to indicate related MIME body parts Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu In-Reply-To: <9310252133.AA11851@thud.cs.utk.edu> References: <9310252133.AA11851@thud.cs.utk.edu> Excerpts from mail: 25-Oct-93 Re: yet another way to indi.. Keith Moore@cs.utk.edu (2631) > Actually, I'm not sure I understand the difference between having a start > parameter that can indicate any body part, and always having "start" be the > first body part (as in header-set). In either case the mail reader has to > look at the headers for that body part before processing the mail. > (but either one of these should be easier to deal with than multipart/foo) I disagree; multipart/foo is certainly easier for metamail than any of these proposals, because you can do the top-level switching (decide what application to run) while processing the enclosing multipart. This is a big win for metamail, which wants to be able to do everything in one pipe-like pass through a MIME message. This is not at all possible with header-set. It is closer to possible with multipart/related, though it would be better if the actual content-type were visible at the enclosing level. Actually, the more I think about it, the more I realize that "start" doesn't buy me much. What I really want in the outer level is the content-type of the "main" inner piece, but I realize it would be a poor idea to include this information twice (because of the opportunity for inconsistency). So I guess I'm out of luck -- NONE of these proposals really permits the one-pass implementation that metamail tries to have. (I say "tries" because multipart/alternative really broke this a long time ago, at the cost of considerable complication in the metamail code...) Given this, I probably still prefer multipart/foo overall! At any rate, I guess I'd agree that you might as well make the first part the "main" one and get rid of "start". After seeing the way multipart/alternative mucked up the code, I am *very* unlikely ever to implement this kind of construct INSIDE metamail; that means I'd end up with a separate handler program for multipart/related. That's not the end of the world, of course, and would probably have been a smarter (though less efficient) way for me to have handled multipart/alternative in the first place. Live and learn. > If the "start" object can't be displayed, sometimes it makes sense to have > the mail reader present the individual objects, sometimes not. If the sender > wants the fallback behavior he should use multipart/alternative for the start > object. Geez, if we're going to have a generic thing like multipart/related, it should at least be able to specify this sort of behavior. How about a parameter, something like multipart/related; displaypiecesifmainunrecognized={yes,no} Seems like this kind of functionality is basic enough to warrant a parameter, though probably one with a better name... :-) -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 22:13:21 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28889; Mon, 25 Oct 93 21:26:21 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28885; Mon, 25 Oct 93 21:26:20 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA13447; Mon, 25 Oct 93 21:26:10 -0400 Message-Id: <9310260126.AA13447@thud.cs.utk.edu> From: Keith Moore To: Dave Crocker Cc: Keith Moore , Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Mon, 25 Oct 1993 17:01:45 PDT." <9310260001.AA18690@Mordor.Stanford.EDU> Date: Mon, 25 Oct 1993 21:26:08 -0400 Sender: moore@cs.utk.edu > Some points for debate > > < comment. Having Keith and me conduct the debate is potentially interesting > -- > though I doubt it -- but distinctly unproductive in determining group > preference.>> > > ---- Included message: > > Actually, I'm not sure I understand the difference between having a > start parameter that can indicate any body part, and always having > "start" be the first body part (as in header-set). > > Only the most obvious distinction comes to mind. Header-set has an > extremely small look-ahead requirement. Since the start parameter can > be on *any* of the body parts and the length of each part is arbitrary, > look-ahead can be painful. It's even a little bit worse than that. The multipart/references proposal requires the mail reader to copy each of the components of the enclosing body parts to a file, before evaluating/presenting/processing the "start" body part. On the other hand, it seems like any practical implementation of header-set would need that also, just so that the module that processes the first component of the header set would be able to read the other components. Keith From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 22:38:35 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28988; Mon, 25 Oct 93 21:43:52 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28984; Mon, 25 Oct 93 21:43:48 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA13613; Mon, 25 Oct 93 21:43:41 -0400 Message-Id: <9310260143.AA13613@thud.cs.utk.edu> From: Keith Moore To: Nathaniel Borenstein Cc: Keith Moore , ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Mon, 25 Oct 1993 20:36:48 EDT." Date: Mon, 25 Oct 1993 21:43:40 -0400 Sender: moore@cs.utk.edu > > Actually, I'm not sure I understand the difference between having > > a start parameter that can indicate any body part, and always > > having "start" be the first body part (as in header-set). In > > either case the mail reader has to look at the headers for that > > body part before processing the mail. > > > (but either one of these should be easier to deal with than > > multipart/foo) > > I disagree; multipart/foo is certainly easier for metamail than any of > these proposals, because you can do the top-level switching (decide what > application to run) while processing the enclosing multipart. This is > a big win for metamail, which wants to be able to do everything in one > pipe-like pass through a MIME message. This is not at all possible > with header-set. It is closer to possible with multipart/related, > though it would be better if the actual content-type were visible at the > enclosing level. The implementation I have in mind is as follows: The mail reader simply extracts each of the components on-the-fly and stores them in appropriately named files (remembering which one is the start body part). Then the start body part is evaluated. You have to store the messages anyway to allow arbitrary cross-referencing. If you didn't want to wire this into metamail, you could just use metamail's normal program calling mechanism to handle the multipart/reference type; the program called could then call metamail recursively to process the "start" body part. > > If the "start" object can't be displayed, sometimes it makes sense to > > have the mail reader present the individual objects, sometimes not. > > If the sender wants the fallback behavior he should use > > multipart/alternative for the start object. > > Geez, if we're going to have a generic thing like multipart/related, it > should at least be able to specify this sort of behavior. How about a > parameter, something like > > multipart/related; displaypiecesifmainunrecognized={yes,no} > > Seems like this kind of functionality is basic enough to warrant a > parameter, though probably one with a better name... :-) -- Nathaniel Okay, but that makes for two levels of fallback, since you can still have a multipart/alternative as the "start" component. And having a boolean option requires the mail reader to display all of the components, not just the ones that make sense. So it seems like a cleaner implementation to use the multipart/alternative containing a multipart/external-body (or possibly multiple external body parts) to indicate which pieces should be displayed for fallback purposes. Keith From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 23:36:33 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29081; Mon, 25 Oct 93 21:52:31 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29077; Mon, 25 Oct 93 21:52:30 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 25 Oct 93 21:52:26 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 25 Oct 93 21:53:17 EDT Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.guppylake.bellcore.com.sun4.41 via MS.5.6.guppylake.bellcore.com.sun4_41; Mon, 25 Oct 1993 21:53:15 -0400 (EDT) Message-Id: Date: Mon, 25 Oct 1993 21:53:15 -0400 (EDT) From: Nathaniel Borenstein To: Keith Moore Subject: Re: yet another way to indicate related MIME body parts Cc: Keith Moore , ietf-822@dimacs.rutgers.edu In-Reply-To: <9310260143.AA13613@thud.cs.utk.edu> References: <9310260143.AA13613@thud.cs.utk.edu> Excerpts from mail: 25-Oct-93 Re: yet another way to indi.. Keith Moore@cs.utk.edu (2639) > If you didn't want to wire this into metamail, you could just use metamail's > normal program calling mechanism to handle the multipart/reference type; the > program called could then call metamail recursively to process the "start" > body part. The problem is the multiplying utilization of the temporary disk. Most mail readers write a temp file to call metamail. To the extent that metamail can do things in pipes from there, it is a big win; in cases like this, it is more or less unavoidable to double that disk usage by then copying each part to a separate file. If the multipart/reference is handled by a separate intermediate program instead of directly by metamail, this could effectively TRIPLE the temporary disk usage. (The "could" is because when things are optimal, some of this can be done with pipelines instead of temp files.) No big deal, assuming you clean it up, until you start getting messages that are bigger than a third the size of the free space on your disk. Maybe I'm compulsive to think about such things, but I've recently been sending messages around that are 1 or 2 megabytes in size. Tripling the temp space required is definitely suboptimal..... > Okay, but that makes for two levels of fallback, since you can still have a > multipart/alternative as the "start" component. And having a boolean option > requires the mail reader to display all of the components, not just the ones > that make sense. So it seems like a cleaner implementation to use the > multipart/alternative containing a multipart/external-body (or possibly > multiple external body parts) to indicate which pieces should be displayed > for fallback purposes. Yes, my only fear is that this puts too much of the burden on the sender to be realistic; pragmatically, the recipients are going to have to cope with stuff that wasn't so nicely laid out, so it would be nice to at least well-define the default semantics for the individual pieces. Actually, this suggests an idea: The spec could say that if you don't recognize the "start" part, you don't show anything. This would effectively FORCE composing software to use multipart/alternative if it wants anything useful to happen for recipients who don't understand the "ideal" semantics. From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 23:48:00 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29125; Mon, 25 Oct 93 22:03:01 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29121; Mon, 25 Oct 93 22:03:00 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA13844; Mon, 25 Oct 93 22:02:46 -0400 Message-Id: <9310260202.AA13844@thud.cs.utk.edu> From: Keith Moore To: sdorner@qualcomm.com (Steve Dorner) Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Mon, 25 Oct 1993 17:05:21 CDT." <199310252205.AA10861@dorner.slip.uiuc.edu> Date: Mon, 25 Oct 1993 22:02:45 -0400 Sender: moore@cs.utk.edu > > When presenting a multipart/references body part, the mail reader > >first scans all of the components contained within. Then it presents > > This is very onerous in certain environments, where spool space is limited > or disk performance is suspect. In transferring an AppleDouble file, I > might wind up writing each part of the file, and then copying one part into > another when the message finally got around to telling me what I was > dealing with. Good point. (Any ideas as to how to make it work better?) --------- > > Required parameters: start > > What is the improvement of being able to designate some later part as the > master part, rather than just using the first one? I'm not sure there is one. It might be better to simply use the first (or last) one. --------- > >Troost's "content-disposition" documents. > > No provision is made for the filename parameter of content-disposition. > This leaves us with no accepted way to hint at a filename, since 1521 > deprecates name=. That's easily remedied by un-deprecating it, I suppose. > > How do we specify that a body part should really be written to a file, not > displayed to the user? content-disposition allowed that; I don't see how > this does, unless the "start" part (could I nominate "control" instead of > "start"?) is known to the mailer. It seems to me that learning new types > is "hard", whereas simply looking for a fixed header value is "easy". I understand people are working on proposals for file transfer body parts; my idea was that the base file could go in an appropriately typed MIME body part, and all of the out-of-band information necessary for file transfer could go in a file-transfer body part that referenced the first part. Presumably the file name information would be included with the other out-of-band info. But whatever the mechanism, I agree that we still need a way to specify a file name. --------- > >multipart/references ; start=D { > > A: [body-part-A] > > B: [body-part-B] > > C: [body-part-C] > > D: multipart/alternative { > > application/foo (which references A, B, and C internally) > > multipart/mixed > > message/external-body; access-type=internal; content-id=A > > message/external-body; access-type=internal; content-id=B > > message/external-body; access-type=internal; content-id=C > > } > >} > > Nit: in part D, shouldn't the application/foo come last, as the "most > preferred" part? yep. --------- > How would I represent a file in AppleDouble using this scheme? Assuming a > benign (instead of pathological) ordering, I guess something like: > > multipart/references ; start=A { > A: application/appledouble > > > B: application/applefile > C: image/gif > } > > So I need "appledouble" (which describes the start section), and > "applefile" to do what I need to do. You will ALWAYS need to define at > least two types for each composite type; one that describes what sort of > composite type it is and how the parts fit together, and one for the > "extra" or "optional" information. AppleDouble may be an unusual case, because both the data and the resource fork are well-defined as separate entities. For another example, a file transfer might look like this: multipart/references; start=A { A: application/file-xfer B: image/gif (or other appropriate mime type) } --------- > How do I represent the fact that some of the data parts are optional, and > that the mailer shouldn't bother the user if it doesn't understand them? > Must I ALWAYS make the start part be multipart/alternative? > > multipart/references ; start=A { > A: multipart/alternative { > message/external-body; access-type=internal; content-id=C > application/appledouble > > > } > B: application/octet-stream > C: image/gif > } > > Under header-set, I accomplish what I need with far less mechanism: > > multipart/header-set { > application/applefile > image/gif > } > > This seems to me a lot easier to deal with, at least for my problem. I can > see that references might work better for other problems. The multipart/alternative + multipart/mixed + message/external-body "internal" lets the sender specify *which* parts should be displayed if it can't deal with the primary start part of the multipart/references. It makes for ugly MIME, but (I believe) it introduces very little new implementation overhead. (only the "internal" part is new, and it is just a veneer on top of "local-file"). Sometimes you may not want the individual contents to be displayed, or want only certain ones to be displayed. Part of it depends on whether the individual contents are useful by themselves. (but if they weren't, would they have real MIME types? hmmm.) thanks for your comments. Keith From owner-ietf-822@dimacs.rutgers.edu Mon Oct 25 23:41:25 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29167; Mon, 25 Oct 93 22:21:30 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29163; Mon, 25 Oct 93 22:21:28 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA14070; Mon, 25 Oct 93 22:21:22 -0400 Message-Id: <9310260221.AA14070@thud.cs.utk.edu> From: Keith Moore To: Nathaniel Borenstein Cc: Keith Moore , ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Mon, 25 Oct 1993 21:53:15 EDT." Date: Mon, 25 Oct 1993 22:21:20 -0400 Sender: moore@cs.utk.edu > > If you didn't want to wire this into metamail, you could just use > > metamail's normal program calling mechanism to handle the > > multipart/reference type; the program called could then call > > metamail recursively to process the "start" body part. > > The problem is the multiplying utilization of the temporary disk. Most > mail readers write a temp file to call metamail. To the extent that > metamail can do things in pipes from there, it is a big win; in cases > like this, it is more or less unavoidable to double that disk usage by > then copying each part to a separate file. If the multipart/reference > is handled by a separate intermediate program instead of directly by > metamail, this could effectively TRIPLE the temporary disk usage. (The > "could" is because when things are optimal, some of this can be done > with pipelines instead of temp files.) No big deal, assuming you clean > it up, until you start getting messages that are bigger than a third the > size of the free space on your disk. > > Maybe I'm compulsive to think about such things, but I've recently been > sending messages around that are 1 or 2 megabytes in size. Tripling the > temp space required is definitely suboptimal..... I'm concerned about that too. There are ways around this, but they're not simple. As long as there's a copy of the whole message on random-access storage, the called programs can access that. The calling mail reader could keep track of the start position and length of each component's header and body, and write *those* to a file, but then the called program would have to do its own decoding. (How many of the programs in the average mailcap file *already* require the body part to be stuffed in its own file?) Basically I figure that if we're going to let body parts reference one another, we have to pay the extra overhead. It's similar to what you pay to get multipart/parallel. (But is it worth the extra overhead to do things like appledouble, file transfer, delivery reports?) Maybe the mailcap file could have a way to specify "don't split up the files for me; just give me the filename and offset of the first component body part (after the start component), and the length of the body part, and I'll read it from there". (But it would be nice if the called programs didn't have to parse MIME headers or understand content-transfer-encodings...) > > Okay, but that makes for two levels of fallback, since you can still > > have a multipart/alternative as the "start" component. And having a > > boolean option requires the mail reader to display all of the > > components, not just the ones that make sense. So it seems like a > > cleaner implementation to use the multipart/alternative containing > > a multipart/external-body (or possibly multiple external body parts) to > > indicate which pieces should be displayed for fallback purposes. > > Yes, my only fear is that this puts too much of the burden on the sender > to be realistic; pragmatically, the recipients are going to have to cope > with stuff that wasn't so nicely laid out, so it would be nice to at > least well-define the default semantics for the individual pieces. > > Actually, this suggests an idea: The spec could say that if you don't > recognize the "start" part, you don't show anything. This would > effectively FORCE composing software to use multipart/alternative if it > wants anything useful to happen for recipients who don't understand the > "ideal" semantics. Yes. (I thought this was obvious, but the spec could certainly be specific about this point.) Keith From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 02:07:58 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29824; Tue, 26 Oct 93 01:10:49 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29820; Tue, 26 Oct 93 01:10:47 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA15285; Tue, 26 Oct 93 01:10:36 -0400 Message-Id: <9310260510.AA15285@thud.cs.utk.edu> To: C.J.Adie@edinburgh.ac.uk Subject: comments on SHAVE Cc: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu From: Keith Moore Date: Tue, 26 Oct 1993 01:10:35 -0400 Sender: moore@cs.utk.edu First of all, I think using SGML to represent attribite/value information is a wonderful idea, and the general approach of SHAVE is quite good. But I'm wondering if we can't get away with something simpler, or at least a simpler way of describing it. Unfortunately, SGML is a culture in itself. It has its own vocabulary, and its own conventions that are strange to those in other lands. MIME also is a culture. My experience so far is that it's difficult enough for outsiders to assimilate the MIME culture, without having to learn SGML also. It appears that if I want to design an application using SHAVE, I have to know enough SGML to write a DTD. It also appears that if I want to parse a SHAVE formatted body part, I need to either have the DTD or know which SHAVE parameters have which kinds of values. (else how do I know when to look for a matching end-tag and when not to?) What I'd like to have is a generalized parser for any SHAVE body part, that does not need to know the DTD or equivalent information, in order to extract the relevant parameters and values from the body part. Of course such a parser wouldn't be able to do full syntax checking (e.g. it wouldn't know which attribute names were valid for a particular element), but for many applications this would not be a problem. One way to do this might be to require each parameter names to have a suffix character which indicated what kind of values it takes. For example, a parameter name that takes a single text value could end with a '+', one that takes a sequence of parameter/value pairs could end with a '/', one that takes a list of text values could end with a '%', etc. (I don't know which of these would work within SGML, but surely there are a few non-alphabetic characters which are legal for this purpose.) SHAVE would be easier to use if it first defined the SHAVE syntax in non-SGML terms (say with an 822-style grammar). A later section would describe how SHAVE fits into the SGML world. It would also be helpful if there were a simple way to describe a SHAVE document, which could be mechanically translated into an SGML DTD. What follows are nits: + a limit of 8 characters on element and attribute names would be very painful. Does it break SGML compatibility to extend this a bit? + it might be nice to provide an alternate way of including arbitrary octet-strings as values, say by encoding them in base64. (maybe a reserved tag/end-tag pair?) + if I understand rule 17, there's no way to encode a string like "this is a string\r\n" because the trailing \r\n will be discarded (even if there are multiple newlines). Keith Moore From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 04:39:15 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01350; Tue, 26 Oct 93 04:04:05 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01346; Tue, 26 Oct 93 04:04:01 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 01:03:21 PST Date: Mon, 25 Oct 1993 22:55:17 -0800 (PST) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Mon, 25 Oct 1993 20:36:48 -0400 (EDT)" To: Nathaniel Borenstein Cc: Keith Moore , ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Message-Id: <01H4JT2QM2608WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > I disagree; multipart/foo is certainly easier for metamail than any of > these proposals, because you can do the top-level switching (decide what > application to run) while processing the enclosing multipart. This is > a big win for metamail, which wants to be able to do everything in one > pipe-like pass through a MIME message. This is not at all possible > with header-set. It is closer to possible with multipart/related, > though it would be better if the actual content-type were visible at the > enclosing level. I agree most emphatically with Nathaniel here. In fact, I will go further and state that I find all of these proposals to be contrary to what I see as the MIME philosophy, anwhere from excruciatingly difficult to completely impossible to implement, and providing no tangible advantage for any proposed multipart object I have seen thus far. The issue here for me is extremely simple. I need to know what sort of multipart entity I'm dealing with at the point where I encounter it. I don't want to have to wade through the entire thing looking for some random part and then have to take that part apart to figure out what I'm supposed to do with the whole collection. This is totally unacceptable to me. Let me deal with my points here one by one: (a) Contrary to the MIME philosophy. The MIME approach is structurally very similar to a textual document: we announce one or more somethings and then they appear. This similarity is quite deliberate. In the case of documents, it make them easier for people to read. It also makes MIME objects easier for people to figure out, both manually and in the code they write. The resulting software is both simpler and easier to maintain. There is only one exception to this in all of MIME: multipart/alternative part ordering. This one exception was made as a sop to the installed base, and the jury is definitely still out on it. It was felt that the benefits to the installed base outweighed the complexity it induces in user agents. (Note that this penalty is pretty much limited to user agents and is not shared by other sorts of MIME-ware. Note also that if we're to cater to the installed base again we should summarily reject both of these proposals right now.) Now let's consider this proposal in the context of a text document, as I have always done with all other MIME entities. It is like having a section head that says "I don't know what this is, see subsection twenty to find out what this stuff means". What would you say about a text document that contained such a thing? (b) Difficult/impossible to implement. A simple real-world example will suffice to illustrate this. Let's suppose that multipart/appledouble gets implemented as multipart/related. I happen to have a gateway that needs to convert multipart/appledouble into MacBinary format. Most other multipart/related parts need to stay in their original text form. Keith has already described how multipart/related pretty much has to be implemented: I now have to write each part into a buffer (my buffering is done in memory with file fallback since disk files are way too much overhead). Only once I'm irretrievably committed to disassembly do I know whether or not I've done the right thing. (The fact that multipart/header-set always uses the first part for labelling is no help since I can neither back out my decision to disassemble nor back up my input stream without a lot of extra structure-breaking code.) If I haven't done the right thing I now have to reassemble the part. Doing so effectively doubles the amount of code involved. I call this excruciating, especially when a single parameter in the right place would make it unnecessary. Now, as to flatly impossible. Steve Dorner points out that this whole thing causes real problems on low-end systems. He's absolutely right, but that's not my problem. My concern is what this does to high-performance gateways. The gateway I've been talking about has to be able to handle average throughputs of 20,000 messages a day. (One message every 4 seconds or thereabouts average, but it isn't evenly distributed throughout the day.) Most sites running serious gateways simply don't have the resources to blow on doubling message processing overhead. Of course not every message is going to be multipart/related. In fact, very few will be to begin with. But high-performance gateways like these always operate just below the knee of a curve. Up the overhead and you may receive more messages than you can send. This messages than it can send. The resulting backlogs can push you past the knee into nonlinear performance. (This is usually, but not always, filesystem-related.) The backlogs can then grow exponentially. (You know you're headed for trouble if you're building up a backlog during the day that only clears at night. When you're "flirting with the knee" like this you need to start watching very closely, because if it ever wraps around into the next day your system may well melt down completely.) To the extent that multipart/related throws a considerable degree of unpredictability into the overall process, it is a Very Bad Thing indeed. There is no way I can provide these gateways with a useful means to deal with the present multipart/related proposal. The constraints are just too tight. (c) No tangible benefit. This is simple. There isn't a single multipart proposal I'm aware of that employs any of the sophisticated stuff multipart/related has to offer. (Maybe the SGML one does, but I haven't read that one yet. The two major proposals I see being affected are multipart/appledouble and multipart/pem.) It is also far from clear that the mechanisms provided by multipart/related are going to be the right fit to future multipart objects that *do* contain references. The issues of how this integrates into the equivalent X.400 mechanism (yes Virginia, there is one in X.400 -- I'll leave the exercise of finding it to the reader) hasn't been dealt with either. Nor does multipart/header-set offer any advantage over simply defining multipart/whatever. I'm sorry, but the added semantics of "these things are related somehow" don't impress either me or the gateways I write. I don't know how to deal with such nebulous semantics meaningfully. I have to have specific information. And existing software is going to treat either one of these as multipart/mixed anyhow, as the MIME specification mandates! > Actually, the more I think about it, the more I realize that "start" > doesn't buy me much. What I really want in the outer level is the > content-type of the "main" inner piece, but I realize it would be a poor > idea to include this information twice (because of the opportunity for > inconsistency). I disagree that this implies duplication of information. There's nothing that says that the "subtype" of multipart object either can or should be in 1-1 correspondence with the type information of the header part. As a matter of fact, both multipart/pem and multipart/appledouble already violate this rule. The former allows application/pem-header to appear outside of a multipart structure and the latter uses application/applefile for both standalone AppleSingle and as the identifing part of application/appledouble. I take the fact that the first two multipart objects with related parts we've dealt with both violate the supposed 1-1 relationship as a sure sign of things to come. I suspect it won't be long before someone comes up with a single multipart/related structure that admits multiple identifying header part types. > Geez, if we're going to have a generic thing like multipart/related, it > should at least be able to specify this sort of behavior. How about a > parameter, something like > multipart/related; displaypiecesifmainunrecognized={yes,no} This simply adds insult to injury. Now I have a parameter on the outer container whose meaning cannot be determined until I look inside the object. This just further illustrates how lopsided these things are. Folks, both of the present proposals in their present form are bad news. I think they should both be dumped in favor of multipart/whatever. And if we must have them, then for heaven's sake let's put the information about what type of grouped object we're dealing with where it belongs, if not in the subtype then at least in a parameter. Failure to do so is a complete showstopper for me. Ned From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 05:09:14 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01417; Tue, 26 Oct 93 04:32:49 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01413; Tue, 26 Oct 93 04:32:47 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 01:32:29 PST Date: Tue, 26 Oct 1993 01:23:40 -0800 (PST) From: Ned Freed Subject: RE: Query on a nit: Application vs. Text conten-type In-Reply-To: Your message dated "Mon, 25 Oct 1993 11:12:34 -0700" <9310251812.AA14235@Mordor.Stanford.EDU> To: Dave Crocker Cc: Ned Freed , ietf-822@dimacs.rutgers.edu Message-Id: <01H4JU3UQPC28WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > Well, STIF is not a distinct type, but PCI uses STIF and I chose to class it > as Content-type:Text on the theory that humans ought to be quite comforable > reading the stuff. (That was, after all, a design goal for STIF.) Sounds like you made the right choice. > The spec for Signature uses Application. I haven't read the signature specification in any detail, but offhand I'd say this is one subtype that needs to be under text! And if there's some reason the data itself isn't sufficiently text-like, I'd say that its the data format that needs to change rather than the grouping! > Those are the two that pop to mind immediatley. If I foraged, I'd probably > come up with more. Lots of conversations have also triggered this question. A quick glance over the current IANA registry shows no subtypes of application that I could see belonging under text, plus one text subtype not in the base MIME specification which nicely illustrates that this point isn't something registrars have overlooked. Ned From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 05:36:48 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01434; Tue, 26 Oct 93 04:37:17 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01430; Tue, 26 Oct 93 04:37:14 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 01:36:57 PST Date: Tue, 26 Oct 1993 01:34:44 -0800 (PST) From: Ned Freed Subject: RE: Query on a nit: Application vs. Text conten-type In-Reply-To: Your message dated "Mon, 25 Oct 1993 11:30:08 -0500" <199310251630.AA10371@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: Dave Crocker , ietf-822@dimacs.rutgers.edu Message-Id: <01H4JU9DT6708WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > - We have to worry about newline conversion. Encoders and decoders need to > know whether line breaks should be mapped to CRLF and vice-versa. Anyone > registering a text subtype should specify this. (Anyone registering any > subtype should specify it, I think.) As Steve knows from extended off-list conversation, I'm in complete agreement with this. > - I know of one WP that stores its text largely as plain text, but in > random chunks of no particular size or order. Is it worthwhile to call > this a text subtype? If not, then we have a guideline about presenting > text in order. :-) This one is a real judgement call. Personally, I'd say "probably not", since the bad effect of tossing garbage all over people's screens probably outweighs the fact that there's some legible text in there. Email is not supposed to be a treasure hunt. Ned From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 09:06:40 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02163; Tue, 26 Oct 93 08:49:04 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02158; Tue, 26 Oct 93 08:49:03 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA04998; Tue, 26 Oct 93 05:48:59 -0700 Message-Id: <9310261248.AA04998@Mordor.Stanford.EDU> To: Keith Moore Cc: ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 25 Oct 93 22:02:45 -0400. <9310260202.AA13844@thud.cs.utk.edu> Date: Tue, 26 Oct 93 05:48:58 -0700 From: Dave Crocker X-Mts: smtp On the matter of sending files inside email body parts, I'd like to note that there is a BOF scheduled for Houston on this matter. The MIMEFTP BOF is scheduled for Thursday at 1:30(pm). d/ From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 09:36:46 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02775; Tue, 26 Oct 93 09:29:07 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02771; Tue, 26 Oct 93 09:29:06 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA05337; Tue, 26 Oct 93 06:29:02 -0700 Message-Id: <9310261329.AA05337@Mordor.Stanford.EDU> To: EDI List Cc: ietf-822@dimacs.rutgers.edu Subject: EDI Mime body part Contact: phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Tue, 26 Oct 93 06:29:02 -0700 From: Dave Crocker X-Mts: smtp Folks, In preparing for a presentation at the Vancouver SPEEDE/ExPRESS conference, last week, I cobbled together the core of a specification for doing EDI as a MIME body part. The purpose of the spec is to trigger discussion, rather than to be submitted (yet) for registration. I have had *some* discussions with others about the spec, but not much and not with many. I am copying both the edi and 822 lists since this affects both and neither has much background with the other. My guess is that whatever initial discussion takes place should be moved to (perhaps) a special email list for this. Anyone volunteer to establish one? (For the 822 list, the conference was for academic institutions using formal, official, standardized X12 EDI to send student transcripts. My view is that their data should, therefore, be treated simply as generic EDI.) Two technical issues were raised at the conference and viewed as barriers to use of email: 1. Reliability/performance, especially with respect to the sending of large files. I notes that Mime fragmentation is the answer to the large-file issue, though it is not yet in heavy use. End-to-end reliability is being addressed (pun?) by the proposals for delivery ack. Performance is a matter of debate. 2. Security. This stuff at least needs authentication, data integrity and confidentiality. There is a strong faction within the SPEEDE/ExPRESS community that prefers use of FTP because it does not let the data reside in a transit disk queue for unknown periods of time. I agree with this concern, with respect to *current* email operations, but note that these requirements are entirely in line with the mail security work already underway. I.e., they must be solved anyhow. I am attaching the draft spec because it is quite short and because it is too close to the IETF meeting to get it put into the I-D repository. - - - - - Internet Draft Application/EDI-X12 (Expiration: 4/94) D. Crocker Network Working Group D. Crocker Internet Draft: Expiration <4/94> MIME Application/EDI-X12: A Working Draft Proposal Status of This Memo This is a preliminary draft document, intended for eventual submission to the IETF working group process. At this stage, the document should be viewed strictly as a think-piece, with comments, corrections, etc. eagerly sought. Summary Inter-organization information exchanges often involve highly regularized transactions. In recent years, many such transactions have been specified in terms of a technology known as EDI (Electronic Data Interchange). One line of this work has been done by the ANSI X12 working group. This document specifies the fram ework for transmission of ANSI X12 EDI transaction units within MIME message. Table Of Contents 1. Introduction 2. Header-Set Content-Subtype Usage in MIME 3. APPLICATION/EDI-X12 Specification 4. APPLICATION/EDI-X12 Usage 5. References 6. Security Considerations 7 Acknowledgments 8. Contact 1. Introduction <> 2. Header-Set Content-Subtype Usage in MIME Header-Set information is specified by: MIME type name: APPLICATION MIME subtype name: EDI-X12 Required parameters: TS (see below) Optional parameters: none Encoding considerations: none Security considerations: See separate section in the document . Published specification: Contained in the following section. Rationale: The ANSI X12 EDI specifications are accepted standards for a class of inter-organization transactions; this permits their transmission over the Internet, via email Contact-info: See Contact section, below. Detail specific to MIME-based usage: This is a generic mechanism for sending any ANSI X12 transaction set. The TS parameter on the Content-type header is used to specify the particular EDI transaction set that is included. 3. APPLICATION/EDI-X12 Specification The APPLICATION/EDI-X12 MIME body-part contains data as specified for electronic data interchange by ANSI X12. 4. APPLICATION/EDI-X12 Usage Assume that a user is sending data from the FOO file system, with its file-system specific information registered as Application/Filesys-FOO, and the user data containing US-ASCII text: To: <> Subject: From: <> Date: Mime-Version: 1.00 Content-Type: APPLICATION/EDI-X12; TS=146 (request transcript) <> 5. References [Bore92] Borenstein, N. & Freed, N., RMime (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing The Format of Internet Message Bodies. March, 1992, Network Information Center, Rfc 1341. 6. Security Considerations EDI transactions typically include senstivie data, so that transmission usually at least needs to account for authentication, data integrity, privacy, and access control concerns. This specification permits transmission of such sensitive data via Internet mail. It does no