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 not provide special security-related mechanisms. As needed and appropriate, such mechanisms MUST be added to the Internet EMail service for this capability to provide sufficient protection of EDI records. 7 Acknowledgments 8. Contact Name: David H. Crocker; Email: dcrocker@mordor.stanford.edu; Phone: +1 408 246 8253; Fax: +1 408 249 6205> From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 10:39:12 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03444; Tue, 26 Oct 93 09:57:49 EDT Received: from [192.105.32.2] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03428; Tue, 26 Oct 93 09:57:18 EDT From: RCB@spsup-1.navy.mil (CHRIS R BARTRAM) Message-Id: <0010KR@KIRK.UII.COM> X-Mailer: NetMail/3000 [Version A.05 93/10/18] Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 26 Oct 1993 09:54:32 -0500 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re[2]: yet another way to indicate related MIME body parts To: ietf-822@dimacs.rutgers.edu In <9310260001.AA18690@Mordor.Stanford.EDU> Dave Crocker writes: > ---- 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 t > he > 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. Our implementation makes a look-ahead through an entire message a less- than-efficient and potentially annoyingly slow prospect. I like the idea of a header-set or at least a first-body-part containing the reference info... -Chris Bartram From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 11:09:12 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03992; Tue, 26 Oct 93 10:52:54 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03988; Tue, 26 Oct 93 10:52:52 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 26 Oct 93 10:52:43 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 26 Oct 93 10:53:34 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; Tue, 26 Oct 1993 10:53:33 -0400 (EDT) Message-Id: Date: Tue, 26 Oct 1993 10:53:33 -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: <9310260221.AA14070@thud.cs.utk.edu> References: <9310260221.AA14070@thud.cs.utk.edu> Excerpts from mail: 25-Oct-93 Re: yet another way to indi.. Keith Moore@cs.utk.edu (3620) > 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. Ugly. The nice thing about separate files in unencoded form is that non-MIME aware apps can often work well with them. > (How many of the programs in the average mailcap file *already* require the > body part to be stuffed in its own file?) Not all of them, by any means, and those that can take their data via stdin get big efficiency gains, on UNIX at least. > 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?) Yes, actually it probably is worth it. The question is still whether the general mechanism adds anything to what you can implement by subtypes such as multipart/appledouble or multipart/enabled-mail. -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 11:39:16 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04073; Tue, 26 Oct 93 11:00:13 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04069; Tue, 26 Oct 93 11:00:12 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 26 Oct 93 11:00:07 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Tue, 26 Oct 93 11:00:58 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; Tue, 26 Oct 1993 11:00:57 -0400 (EDT) Message-Id: Date: Tue, 26 Oct 1993 11:00:57 -0400 (EDT) From: Nathaniel Borenstein To: Ned Freed Subject: Re: yet another way to indicate related MIME body parts Cc: Keith Moore , ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu In-Reply-To: <01H4JT2QM2608WVZ4V@INNOSOFT.COM> References: <01H4JT2QM2608WVZ4V@INNOSOFT.COM> As usual, Ned has stated the case more clearly than I managed to. Thanks, Ned. Excerpts from mail: 25-Oct-93 RE: yet another way to indi.. Ned Freed@INNOSOFT.COM (8738*) > The two major > proposals I see being affected are multipart/appledouble and > multipart/pem.) Don't forget multipart/enabled-mail. > 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. Note also that if you see multipart/foobar, it's probably safe to assume that the parts are related somehow, so it can be argued that there are no added semantics anyway. Keith's was the first proposal of this kind that had any appeal to me at all, but I'm now back where I was, and where Ned is -- seeing virtually no advantage to these proposals, and a considerable downside. -- NB From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 12:29:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04250; Tue, 26 Oct 93 11:16:13 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04246; Tue, 26 Oct 93 11:16:12 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA09156; Tue, 26 Oct 93 08:14:06 -0700 Message-Id: <9310261514.AA09156@Mordor.Stanford.EDU> To: RCB@spsup-1.navy.mil (CHRIS R BARTRAM) Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: 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 Tue, 26 Oct 93 09:54:32 -0500. <0010KR@KIRK.UII.COM> Date: Tue, 26 Oct 93 08:14:06 -0700 From: Dave Crocker X-Mts: smtp To deal only with the matter of "header" position and reference -- ignoring various other features under discussion -- I'd like to ask the list for some feedback on the following point of distinction: Is it acceptable to require that the 'header' body part be at the beginning or is there particular benefit in letting it be anywhere in the multipart set? To carry the question a bit further: How onerous is it to have to look ahead a couple of lines, versus an arbitrary amount? We have several comments that are unhappy with arbitrary and one that is very unhappy with ANY look-ahead. My own leanings: Implementation and performance efficiencies are important. If look-ahead -- even for a few lines, but into the "next" body part -- is onerous, then we should not do it. I continue to believe we should have a generic multipart construct. This is probably a matter of philosophy rather than compelling, technical requirement. I think it would be cleaner not to have to register a multipart name for every tailored use of multipart, when there is also at least one other content-type being registered. Hence, I'm leaning towards suggesting that the header-set (or equivalent) spec call for the generic, encapsulating multipart to have a parameter that names the content-type of the 'header', replicating the value put into the content-type for that other body part, and to specify a content-id to distinguish which of the body parts to treat as the header. This is substantially more complicated than I had originally wanted, but the concern for operational efficiency is serious. Comments? Dave From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 12:54:28 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05871; Tue, 26 Oct 93 12:12:53 EDT Received: from Princeton.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05864; Tue, 26 Oct 93 12:12:51 EDT Received: from acupain.UUCP by Princeton.EDU (5.65b/2.101/princeton) id AA15064; Tue, 26 Oct 93 11:44:41 -0400 Received: from localhost by Accurate.COM (4.1/SMI-4.0) id AA16386; Tue, 26 Oct 93 11:13:28 EDT Message-Id: <9310261513.AA16386@Accurate.COM> To: Dave Crocker 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 "Tue, 26 Oct 93 05:48:58 PDT." <9310261248.AA04998@Mordor.Stanford.EDU> Organization: Accurate Information Systems, Inc. X-Mailer: MH 6.7 Date: Tue, 26 Oct 93 11:13:27 -0400 From: "Ed Levinson" Dave, I'd like to join you and others in a discussion of multipart/ {header, related, reference, etc.} at Houstion. Unfortunately, I'll only be there on Mon and Tue. The mime-sgml proposal (a multipart/foo approach) uses a header "Content-Reference:" to make the internal file references visible. I could use Keith's proposal as well. I haven't read the header-set proposal as yet. A design goal (unstated naturally ;-) of the mime-sgml proposal is to be able to use existing, MIME ignorant, software to do the SGML processing. There has to be some middleware software that understands enough SGML to rebind the MIME parts to the receiver's file system names. I can see how to do this in a number of ways; I intend to build the middleware using the existing MIME software; the middleware is, in part, a MIME UA that just stores the body parts and then invokes the "real" application. Ed From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 13:46:24 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04813; Tue, 26 Oct 93 11:51:36 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04809; Tue, 26 Oct 93 11:51:33 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA16510 (5.67a/IDA-1.5 for ); Tue, 26 Oct 1993 10:50:59 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA11772 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Tue, 26 Oct 1993 10:52:31 -0500 Message-Id: <199310261552.AA11772@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1993 10:51:57 -0500 To: Keith Moore , Nathaniel Borenstein From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: yet another way to indicate related MIME body parts Cc: Keith Moore , ietf-822@dimacs.rutgers.edu At 9:43 PM 10/25/93 -0400, Keith Moore wrote: >You have to store the messages anyway to allow arbitrary cross-referencing. At this point in time, I don't support arbitrary cross-referencing. All I need to implement what I'm interested in (Macintosh file transfer) is the ability to do a very limited sort of cross-referencing; namely, the association of some sizeable attributes with a file. It seems like multipart/references makes this simple task much more complicated. Now, perhaps the arbitrary referencing of multipart/related is so insanely useful that I should make it possible anyway, and then let appledouble just fall out of it. However, at this point, I am unconvinced that this is so (real-world examples might help). >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. My implementation of header-set does not work that way. The model that header-set fits is "here is some extra stuff that goes with this data". It's relatively easy to cache the "extra stuff" (or even do the right thing with the extra stuff) before reading the data. Consider AppleDouble: the header part is the "resource fork" and file type information. I see this, I create the file, apply the type, dump the resource fork stuff into the file's resource fork. Now, for the data part, I just open the data fork and write the contents. The only special handling required for the data part is to remember to use the same filename as for the resource fork. Or UNIX permissions: the header part is (eg) uid, gid, and permissions. I create the file, set the permissions. Then for the data part, I just dump in the data. In neither of these (admittedly simple; that's what header-set is good at) examples was it necessary to have the data in hand before processing the header part of the header-set. At 8:36 PM 10/25/93 -0400, Nathaniel Borenstein wrote: >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, I, too, make one big pipe-like pass through a MIME message. I found (to my delight) that multipart/header-set took NO code changes at all over how I was handling multipart/foo. My multipart handler has always delayed its decision on what to do with a multipart until it read the first part. It was simpler to code that way, and provided a bit of failure handling as well (in case multipart/foo had the wrong parts, this allowed me to fall back to multipart/mixed handling). Multipart/references scares the heck out of me on this ground, because I do not know until I get to the "start" part what the pieces mean. I *must* save them separately, and go back to them later, unless the "start" part is at the beginning. Multipart/references becomes less scary for me if the start parameter is eliminated and the first part is used as the start part. I can read and digest the start part, and know in advance what I must do with the other parts. Yes, if the start part represents a compound document instead of the simpler attributes-for-data kind of thing, the reader may have to wait to display the start part until the body parts are read, and this may require caching the start part to a temporary file or in memory. But I suspect that (more often than not) the start part is going to be significantly smaller than the data parts, and so this will be less of a problem than the other way around. While putting the start part first would help, I still prefer the simplicity of header-set for simple problems like AppleDouble. Header-set gives me a multipart and two body parts, whereas references ends up being two multiparts and four body parts; that's twice as many parts, and so twice the opportunity to shoot myself in the foot. Would it be too terrible to keep header-set for simple problems, and use references for more complex ones? Yes, that gives us two multipart things that perform similar functions. But header-set solves in a simple way what looks to me to be a common, simple problem, whereas references solves simple problems with much greater difficulty. Sorta like increment operators vs assignment with expressions in C. -- 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 Tue Oct 26 14:12:32 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09613; Tue, 26 Oct 93 13:03:52 EDT Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09562; Tue, 26 Oct 93 13:03:49 EDT Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA24941; Tue, 26 Oct 93 18:03:06 +0100 Message-Id: <9310261703.AA24941@nada.kth.se> To: Nathaniel Borenstein Cc: Ned Freed , Keith Moore , ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Tue, 26 Oct 1993 11:00:57 -0400." Date: Tue, 26 Oct 1993 18:03:04 +0100 From: Patrik Faltstrom Nathaniel Borenstein writes: >Keith's was the first proposal of this kind that had any appeal to me at >all, but I'm now back where I was, and where Ned is -- seeing virtually >no advantage to these proposals, and a considerable downside. -- NB I am in the same domains as Nathaniel so far, i.e. the easiest way of parsing an object which is made up of several parts is to enclose them in one multipart part. That part should be tagged in some way with a description about what kind of object it is, to make the parsing easier. But, Steve says that adding multipart/header-set to Eudora was not hard at all, and there is a point that IF the order of the different parts is decided, one could continue to parse until you find the application/whatever header part and _then_ send it to the parser. I think this is "uglier" than having separate types for the multipart types that exists, and I can still not see why we can't have multipart/whatever... It's easier to understand I think. If sameone make a "WWW"-type with lots and lots of pictures and such in the document, I think that should be a separate type (text with links inside) and not a multipart message. We should not try to use the multipart type for what it isn't. I might be the only one, together with Nathaniel, that didn't understand the magic with header-set or related parts. BUT, note that I think the primary goal in this discussion is to use the SAME method for all of the future multipart messages that exists, i.e. I will never, never use multipart/appledouble if everyone except me thinks for example multipart/header-set is the solution to use! Patrik From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 13:51:53 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06107; Tue, 26 Oct 93 12:44:07 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06103; Tue, 26 Oct 93 12:43:59 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA17818 (5.67a/IDA-1.5 for ); Tue, 26 Oct 1993 11:42:35 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA11902 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Tue, 26 Oct 1993 11:43:02 -0500 Message-Id: <199310261643.AA11902@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1993 11:42:25 -0500 To: ietf-822@dimacs.rutgers.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: yet another way to indicate related MIME body parts I mildly prefer header-set to multipart/foo. I prefer either to multipart/references without the start parameter, and definitely unprefer the start parameter. Header-set has two advantages over multipart/foo. One, the "header" part is known a priori to be optional, and readers that don't understand it know that ignoring it is ok (unlike multipart/unknown-foo, which gets treated like mixed). Two, by making the header part multipart, you can associate multiple sets of header info without repeating the data part. The drawback is that you don't know what the aggregate is until you look inside; for my implementation, this is no problem at all. multipart/references (without start) is a bit more complex, and offers no advantage to what *I* want to do right *now* (AppleDouble). I can see that it's more powerful, but without some concrete examples of how that power is going to be used, I can't say it puts the cream in my coffee. The start parameter is trouble for me. It could force me into using temp files, something I don't need to do for the other three alternatives. -- 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 Tue Oct 26 14:17:26 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10346; Tue, 26 Oct 93 14:05:08 EDT Received: from hp.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10340; Tue, 26 Oct 93 14:05:04 EDT Received: from hpcvxkm.cv.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA17930; Tue, 26 Oct 93 11:05:03 -0700 Received: from localhost by hpcvxkm.cv.hp.com with SMTP (1.37.109.4/15.5+IOS 3.21) id AA21113; Tue, 26 Oct 93 11:03:14 -0700 Message-Id: <9310261803.AA21113@hpcvxkm.cv.hp.com> To: ietf-822@dimacs.rutgers.edu Subject: Subscribe Date: Tue, 26 Oct 93 11:03:14 -0700 From: Keith Marchington Please add me to the ietf-822 mailing list. Keith Marchington Hewlett-Packard Company kam@cv.hp.com From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 14:45:47 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10172; Tue, 26 Oct 93 13:45:41 EDT Received: from RELAY.TIS.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10168; Tue, 26 Oct 93 13:45:40 EDT Received: by relay.tis.com; id AA24313; Tue, 26 Oct 93 13:43:13 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma024310; Tue Oct 26 13:43:03 1993 Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA02171; Tue, 26 Oct 93 13:45:27 EDT Message-Id: <9310261745.AA02171@TIS.COM> To: Dave Crocker Cc: RCB@spsup-1.navy.mil (CHRIS R BARTRAM), ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Tue, 26 Oct 93 08:14:06 PDT." <9310261514.AA09156@Mordor.Stanford.EDU> Date: Tue, 26 Oct 93 13:45:11 -0400 From: Stephen D Crocker Dave, Just to make sure we understand your proposal, are you suggesting something like: Content-Type: multipart/header-set, type = pem-signature, boundary = "aaa" --aaa Content-Type: application/pem-signature ... --aaa Content-Type: application/mime-quoted-entity ... --aaa-- Where: - "header-set" might be replaced by whatever word the community chooses, e.g. "related", etc., - Ditto for "type". - Content-id is an optional header (not present in the above example) that can be used to say which body part is the one to process first. (The default is to process the first body part first.) (I don't have any objection to this proposal; I just want to make sure I understand it. Others can debate its merits. Speaking for our needs, it's as comfortable as any of the proposals. The obvious merit to your proposal is that it provides the structure information up front for those implementations that want it, but it permits other implementations to leave their main multipart processing code alone. Steve From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 15:18:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10362; Tue, 26 Oct 93 14:08:14 EDT Received: from hp.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10358; Tue, 26 Oct 93 14:08:12 EDT Received: from hpcvxkm.cv.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA18045; Tue, 26 Oct 93 11:08:05 -0700 Received: from localhost by hpcvxkm.cv.hp.com with SMTP (1.37.109.4/15.5+IOS 3.21) id AA21138; Tue, 26 Oct 93 11:06:15 -0700 Message-Id: <9310261806.AA21138@hpcvxkm.cv.hp.com> To: ietf-822@dimacs.rutgers.edu Subject: Unsubscribe Date: Tue, 26 Oct 93 11:06:15 -0700 From: Keith Marchington Please UNSUBSCRIBE the following person from the ietf-822 mailing list: gabe@cv.hp.com (Gabe Beged-Dov) From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 15:41:50 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10721; Tue, 26 Oct 93 15:11:23 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10717; Tue, 26 Oct 93 15:11:21 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA23268; Tue, 26 Oct 93 15:11:09 -0400 Message-Id: <9310261911.AA23268@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 "Tue, 26 Oct 1993 11:42:25 CDT." <199310261643.AA11902@dorner.slip.uiuc.edu> Date: Tue, 26 Oct 1993 15:11:04 -0400 Sender: moore@cs.utk.edu > I mildly prefer header-set to multipart/foo. I prefer either to > multipart/references without the start parameter, and definitely unprefer > the start parameter. Yeah, at this point I don't see any reason to keep the start parameter. Just make the first component be the "start" component. That makes it equivalent to multipart/header-set, except that with /references the objects can reference one another. A clever mail reader could then decide, after reading the first component only, whether it should (a) handle the entire multipart internally, (b) run a display program and pipe the object to its standard input (if there's only one object being referenced), or (c) put the component objects into temp files (if the objects reference one another). The real question is: is there a need for MIME objects that can reference one another? I think there is. An application/html document is a single "page", yet you usually peruse them in sets, and mailing a set of such documents around seems like a natural thing to do. (Mac users mail around hypercard, stacks, don't they?) At the same time, I don't want mime mail readers to incur the overhead of copying components of a multipart/references set to separate files, if it's not needed for that application. Keith From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 17:40:33 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11927; Tue, 26 Oct 93 17:06:12 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11923; Tue, 26 Oct 93 17:06:10 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA14211; Tue, 26 Oct 93 14:03:10 -0700 Message-Id: <9310262103.AA14211@Mordor.Stanford.EDU> To: Stephen D Crocker Cc: RCB@spsup-1.navy.mil (CHRIS R BARTRAM), ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: 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 Tue, 26 Oct 93 13:45:11 -0400. <9310261745.AA02171@TIS.COM> Date: Tue, 26 Oct 93 14:03:08 -0700 From: Dave Crocker X-Mts: smtp Steve, Thanks for sending the verification query. All of the details in your note were exactly correct and therefore combine with my original note, I think, to explain the suggestion. Dave From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 18:40:31 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12676; Tue, 26 Oct 93 18:30:55 EDT Received: from netcom.netcom.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12672; Tue, 26 Oct 93 18:30:54 EDT Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA26715; Tue, 26 Oct 93 15:31:28 -0700 Date: Tue, 26 Oct 93 15:31:28 -0700 From: mdg@netcom.com (Mark Grand) Message-Id: <9310262231.AA26715@netcom.netcom.com> To: EDI-L@uccvma.ucop.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: <9310261336.AA22276@mail.netcom.com> (message from Dave Crocker on Tue, 26 Oct 1993 06:29:02 -0700) Subject: Re: EDI Mime body part Dave, I applaud your initiative in writing a draft for an EDI body part. It is something that is very much needed. The organization of the body-part you describe conflicts with or is redundant with the envelope of the EDI it is to contain. Here are the issues that I see: 1. The subtype name EDI-X12 is overly specific. EDI standards other than X12, such as EDIFACT, are in common use, especially outside the US. 2. The TS parameter is inappropriate. The outermost envelope of an EDI transmission is called an interchange. Interchanges can and do contain multiple transactions of different types. The types of the transactions are identified by the envelope of the individual transaction. 3. There are some optional parameters that would be useful to have. Some entities use variants or industry specific version of the major standards. Since there is no way of indicating the use of a variant in an EDI header, this could be useful information. It would be useful to have standard and version as parameters. 4. Though a relatively new feature, both the X12 and EDIFACT standards have provisions for digital signatures and encryption of EDI transactions within the EDI envelope. It would be redundant to develop separate mechanisms for these purposes in the mime body part. From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 19:10:31 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12836; Tue, 26 Oct 93 18:50:08 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12826; Tue, 26 Oct 93 18:50:06 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15383; Tue, 26 Oct 93 15:49:59 -0700 Message-Id: <9310262249.AA15383@Mordor.Stanford.EDU> To: sdorner@qualcomm.com (Steve Dorner) 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 Tue, 26 Oct 93 11:42:25 -0500. <199310261643.AA11902@dorner.slip.uiuc.edu> Date: Tue, 26 Oct 93 15:49:58 -0700 From: Dave Crocker X-Mts: smtp Steve, Thanks for mentioning the "multiple header" feature that fell out from the header-set approach. Amanda Walker suggested it during the MacMime discussions and it seemed pretty nifty to me. It means that you could, for example, send a file which has all of the operating system-speicifc information for BSD Unix, VMS, Dos, and MacOS, all using the same user data portion. d/ From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 22:39:58 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17182; Tue, 26 Oct 93 22:19:30 EDT Received: from black-ice.cc.vt.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17178; Tue, 26 Oct 93 22:19:28 EDT Received: by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03) id AA18878; Tue, 26 Oct 1993 22:18:05 -0400 Message-Id: <9310270218.AA18878@black-ice.cc.vt.edu> To: mdg@netcom.com (Mark Grand) Cc: EDI-L@uccvma.ucop.edu, ietf-822@dimacs.rutgers.edu, valdis@black-ice.cc.vt.edu Subject: Re: EDI Mime body part In-Reply-To: Your message of "Tue, 26 Oct 1993 15:31:28 EDT." <9310262231.AA26715@netcom.netcom.com> From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Oct 1993 22:18:04 +22305706 Sender: valdis@black-ice.cc.vt.edu On Tue, 26 Oct 1993 15:31:28 EDT, you said: > 4. Though a relatively new feature, both the X12 and EDIFACT standards > have provisions for digital signatures and encryption of EDI > transactions within the EDI envelope. It would be redundant to develop > separate mechanisms for these purposes in the mime body part. On the other hand, there is a need for digital signatures and encryption of non-EDI bodyparts as well. Therefor, it would be redundant to develop separate mechanisms for these purposes for the EDI bodypart. Is it possible to converge the X12/EDIFACT stuff with the output of the PEM crew, so we only have to do this *ONCE* and cover everybody? Alternatively, if the PEM scheme provides sufficient functionality, should there be a switch variable someplace that allows the option of using the PEM or EDIFACT scheme? Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 23:10:00 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17286; Tue, 26 Oct 93 22:45:05 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17277; Tue, 26 Oct 93 22:45:03 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H4KO68HAGG934RKD@SIGURD.INNOSOFT.COM>; Tue, 26 Oct 1993 18:40:28 PDT Date: Tue, 26 Oct 1993 18:23:55 -0700 (PDT) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Tue, 26 Oct 1993 10:51:57 -0500" <199310261552.AA11772@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: Keith Moore , Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Message-Id: <01H4KU0CWAXC934RKD@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > My implementation of header-set does not work that way. The model that > header-set fits is "here is some extra stuff that goes with this data". > It's relatively easy to cache the "extra stuff" (or even do the right thing > with the extra stuff) before reading the data. It sure is nice if you're able to implement this cleanly. Unfortunately, I have a real problem with this, since interfaces I don't control insist on me telling them what's going on before I'm ready to. This means than in order to implement this I effectively have to pick up the entire multipart structure and shunt it off somewhere, examine it, and then back up and retry it once I know what's going on. Implementation of this isn't particularly difficult since I have all the MIME parsing code I could ever need. It sure is ugly, though, and the overhead is quite large. > At 8:36 PM 10/25/93 -0400, Nathaniel Borenstein wrote: > > 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, My situation is that I'm at the back end of a MIME pipe and at the front-end of another sort of pipe. Data is written to me in arbitrary chunks. I have to process each chunk and return to my caller, saving whatever state I'm in at the time. In the meantime I have to communicate my wishes to the next part down the line at appropriate points in the process. > I, too, make one big pipe-like pass through a MIME message. I found (to my > delight) that multipart/header-set took NO code changes at all over how I > was handling multipart/foo. I suspect this is a result of having planned to deal with appledouble from the start as the rule rather than the exception. > My multipart handler has always delayed its decision on what to do with a > multipart until it read the first part. It was simpler to code that way, > and provided a bit of failure handling as well (in case multipart/foo had > the wrong parts, this allowed me to fall back to multipart/mixed handling). > Multipart/references scares the heck out of me on this ground, because I do > not know until I get to the "start" part what the pieces mean. I *must* > save them separately, and go back to them later, unless the "start" part is > at the beginning. Agreed. I think we should stick with having the header first unless there is some compelling reason to move it. > Multipart/references becomes less scary for me if the start parameter is > eliminated and the first part is used as the start part. I can read and > digest the start part, and know in advance what I must do with the other > parts. I see this as functionally the same as header-set. > Yes, if the start part represents a compound document instead of the > simpler attributes-for-data kind of thing, the reader may have to wait to > display the start part until the body parts are read, and this may require > caching the start part to a temporary file or in memory. But I suspect > that (more often than not) the start part is going to be significantly > smaller than the data parts, and so this will be less of a problem than the > other way around. Size is less of an issue than complexity for me. Ned From owner-ietf-822@dimacs.rutgers.edu Tue Oct 26 23:39:59 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17276; Tue, 26 Oct 93 22:45:01 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17272; Tue, 26 Oct 93 22:44:59 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H4KO68HAGG934RKD@SIGURD.INNOSOFT.COM>; Tue, 26 Oct 1993 18:13:05 PDT Date: Tue, 26 Oct 1993 17:41:09 -0700 (PDT) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Tue, 26 Oct 1993 08:14:06 -0700" <9310261514.AA09156@Mordor.Stanford.EDU> To: Dave Crocker Cc: RCB@spsup-1.navy.mil, ietf-822@dimacs.rutgers.edu Message-Id: <01H4KT1FH9SM934RKD@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > To deal only with the matter of "header" position and reference -- > ignoring various other features under discussion -- I'd like to > ask the list for some feedback on the following point of > distinction: I'm afraid I see this as an attempt to finesse away the important issues. You're trying to first make a header position choice and then show how this lessens the burden and hence is marginally more acceptable. I see all these issues as tightly intertwined. They cannot be dealt with separately. > Is it acceptable to require that the 'header' body part be at > the beginning No. The only acceptable compromise as far as I'm concerned is to label the object for what it is in the multipart header itself. I would much prefer to simply use multipart/whatever, since I have yet to find any advantage to multipart/header-set, but I can live with "multipart/header-set; subtype=whatever" or "multpart/related; subtype=whatever". > or is there particular benefit in letting it be > anywhere in the multipart set? The multipart/alternative positioning choice springs to mind as one possibility. On the other hand, these objects are now so complex I think that worrying about their appearance on non-MIME systems is no longer an issue. Other than this, I see some benefit to having the header first in terms of implementation. (It helps when writing multipart/appledouble and when reading multipart/pem, for example.) > To carry the question a bit further: How onerous is it to have to > look ahead a couple of lines, versus an arbitrary amount? We have > several comments that are unhappy with arbitrary and one that is > very unhappy with ANY look-ahead. Couple of lines? It can be thousands, you know. It is often 20 or more now, and I expect it to grow significantly in the future. The lookahead issue is really secondary, however. This whole thing is *UGLY*. I don't want to have to read ahead to find out something I should have been told right away. It dirties up my code, making it harder to understand and much more difficult to maintain. And I especially don't want to have to do it when I don't see where I accrue even the tiniest of benefits from all this. > My own leanings: Implementation and performance efficiencies are > important. If look-ahead -- even for a few lines, but into the > "next" body part -- is onerous, then we should not do it. It is terribly, terribly onerous. > I continue > to believe we should have a generic multipart construct. This is > probably a matter of philosophy rather than compelling, technical > requirement. I think it would be cleaner not to have to register > a multipart name for every tailored use of multipart, when there is > also at least one other content-type being registered. I have yet to hear any compelling reasons to have such a thing, philosophical or otherwise. On the other hand, I also have no real problem with this proposal as long as you add the parameter I need. > Hence, I'm leaning towards suggesting that the header-set (or > equivalent) spec call for the generic, encapsulating multipart > to have a parameter that names the content-type of the 'header', > replicating the value put into the content-type for that other > body part, and to specify a content-id to distinguish which of > the body parts to treat as the header. Perhaps in most cases the header parameter will be the same as the inner header's content type, but I don't necessarily see why this needs to be a requirement. There may be cases where a given multipart construct can have different sorts of headers. Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 00:10:07 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17517; Tue, 26 Oct 93 23:41:16 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17513; Tue, 26 Oct 93 23:41:15 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA00496; Tue, 26 Oct 93 23:40:59 -0400 Message-Id: <9310270340.AA00496@thud.cs.utk.edu> From: Keith Moore To: Ned Freed Cc: sdorner@qualcomm.com, 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 "Tue, 26 Oct 1993 18:23:55 PDT." <01H4KU0CWAXC934RKD@SIGURD.INNOSOFT.COM> Date: Tue, 26 Oct 1993 23:40:58 -0400 Sender: moore@cs.utk.edu Ned, I'm having trouble understanding the difference in how your implementation would treat multipart/header-set vs. multipart/foo, and why the latter is significantly less complex than the former. In one case, you would see: ------ content-type: multipart/header-set; boundary=xyzzy --xyzzy content-type: application/foo ... ------ ... and in the second case, you would see: ------ content-type: multipart/foo; boundary=xyzzy --xyzzy content-type: application/foo ... ------ Right? Is the problem just that the MIME parser is already trying to process the inner body part without knowing what it's going to have to do with the rest of the multipart body? (maybe a concrete example would help) In a metamail-like environment, it appears that multipart/foo puts a big burden on the programs that must interpret such body parts, because they have to be able to parse multipart MIME messages. A generalized multipart/related type lets the mail reader deal with parsing the message structure (as long as all of the components of a message are non-composite MIME types), and just pass the primitive parts to sub-programs. (of course, they can still process them internally if they wish for reasons of efficiency). What I think I hear you saying is that this imposes too much of a burden in your environment, where you have to translate the message into some other form on-the-fly. (do I grok?) If that's the case, maybe the idea of having a "type" parameter for the generalized multipart/related bodypart isn't such a bad idea, since it lets both the metamail-style program, and the on-the-fly translator function efficiently. (If the type parameter doesn't match the content-type, gee...the message must be garbled!) Keith From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 01:09:59 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17743; Wed, 27 Oct 93 00:36:36 EDT Received: from netcom.netcom.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17739; Wed, 27 Oct 93 00:36:35 EDT Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA17313; Tue, 26 Oct 93 21:35:56 -0700 Date: Tue, 26 Oct 93 21:35:56 -0700 From: mdg@netcom.com (Mark Grand) Message-Id: <9310270435.AA17313@netcom.netcom.com> To: Valdis.Kletnieks@vt.edu Cc: EDI-L@uccvma.ucop.edu, ietf-822@dimacs.rutgers.edu, valdis@black-ice.cc.vt.edu In-Reply-To: <9310270218.AA18878@black-ice.cc.vt.edu> (Valdis.Kletnieks@vt.edu) Subject: Re: EDI Mime body part Is it possible to converge the X12/EDIFACT stuff with the output of the PEM crew, so we only have to do this *ONCE* and cover everybody? Alternatively, if the PEM scheme provides sufficient functionality, should there be a switch variable someplace that allows the option of using the PEM or EDIFACT scheme? Not really. The X12/EDIFACT stuff is designed to be independant of transprot mechanism. It really has an existance that is independent of e-mail. From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 01:40:00 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17756; Wed, 27 Oct 93 00:43:11 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17748; Wed, 27 Oct 93 00:43:09 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 21:42:49 PST Date: Tue, 26 Oct 1993 21:40:51 -0800 (PST) From: Ned Freed Subject: Re: EDI Mime body part In-Reply-To: Your message dated "Tue, 26 Oct 1993 06:29:02 -0700" <9310261329.AA05337@Mordor.Stanford.EDU> To: Dave Crocker Cc: EDI List , ietf-822@dimacs.rutgers.edu Message-Id: <01H4L0DG21Q48WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Minor stuff: > 2. Header-Set Content-Subtype Usage in MIME > Header-Set information is specified by: I'm not clear on why header-set is mentioned. Perhaps a cut-and-paste error? You also have a 1.00 in one of the MIME-Version headers. Looks fine to me, but of course I'm not competent to speak for the EDI side of things. Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 02:41:26 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17881; Wed, 27 Oct 93 01:29:05 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17877; Wed, 27 Oct 93 01:29:02 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 22:28:17 PST Date: Tue, 26 Oct 1993 21:51:53 -0800 (PST) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Tue, 26 Oct 1993 23:40:58 -0400" <9310270340.AA00496@thud.cs.utk.edu> To: Keith Moore Cc: Ned Freed , sdorner@qualcomm.com, Keith Moore , Nathaniel Borenstein , ietf-822@dimacs.rutgers.edu Message-Id: <01H4L1XUM0VA8WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > Ned, I'm having trouble understanding the difference in how your > implementation would treat multipart/header-set vs. multipart/foo, > and why the latter is significantly less complex than the former. > ... > Right? Yes. > Is the problem just that the MIME parser is already trying to process the > inner body part without knowing what it's going to have to do with the rest > of the multipart body? (maybe a concrete example would help) Well, I gave a concrete example in my original message. There are several ways to deal with a MIME multipart structure. One is to open up a new context in the message being created (if nested structures are supported) and fit the parts into this new structure. Another is to leave the entire multipart alone and encapsulate it inside of a labelled MIME object. A third way to deal with it is to process the collection of parts in some way to produce an appropriate aggregate in the target environment. (Obviously, there are a large number of subcases under this one.) I already see separate instances of multipart/header-set that will correspond to each of these processing options. My goal here is very very simple. I want to know which one of these I need to do when I first encounter the multipart structure. In order to do this I need to know what sort of header-set I am dealing with. If I don't know which one I have to assume the worst when I get to the multipart boundary. I have to preserve all the content- headers for the outer part. I should probably preserve the preamble as well. If the first part is itself a multipart I must recurse, looking through the resulting alternate headers to see which one makes the most sense for me. And I still cannot have committed to any sort of processing at this point. I certainly can implement all this. I can buffer up and reread all this stuff, in most cases preserving information I will never need. But why should I? What is gained by omitting essential labelling information from the place where it makes the most sense to have it? > In a metamail-like environment, it appears that multipart/foo puts a big > burden on the programs that must interpret such body parts, because they have > to be able to parse multipart MIME messages. I disagree. multipart/foo is either recognized, in which case it is handled by an appropriate handler that knows what to do, or it isn't, in which case it is treated as multipart/mixed. In either case the decision is easily made based on the existing mailcap facility. The appropriate handler can easily do whatever it needs to do to the inner parts. Using a header-set parameter to convey the subsubtype of header-set is only marginally less convenient, since it requires some modification to the mailcap format (or a separate file, perhaps). But the hand-off to the proper processor can be done before any of the parts are read. But multipart/header-set with no additional information requires that the first part be read, possibly recursing to handle nested parts, possibly resolving external references, before the proper handling program can even be determined. And let's suppose that after we have the subsubtype information we decide to use our regular handler for multipart/parallel or multipart/mixed. But we cannot do that since the first part has already been shuttled off to some separate location. So now let's crank through the code and add another squirrel file (maybe we'll call this one a rabbit file, for variety) to handle this special case. Yuck! > A generalized multipart/related type lets the mail reader deal with parsing the > message structure (as long as all of the components of a message are > non-composite MIME types), and just pass the primitive parts to sub-programs. > (of course, they can still process them internally if they wish for reasons of > efficiency). Right. > What I think I hear you saying is that this imposes too much of a burden in > your environment, where you have to translate the message into some other > form on-the-fly. (do I grok?) You do. > If that's the case, maybe the idea of having a "type" parameter > for the generalized multipart/related bodypart isn't such a bad idea, since it > lets both the metamail-style program, and the on-the-fly translator function > efficiently. (If the type parameter doesn't match the content-type, gee...the > message must be garbled!) As I've said previously, I'm far from sure that this is duplicate information. Our extant header-set headers can and do function outside of header-set objects. It is only a matter of time before we come up either some kind of multipart object that admits two different headers or a header that services two different subtypes of multipart. (The more I think about this last point the more I think we'll be crying into our beverages later if we do this wrong.) Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 02:10:10 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17813; Wed, 27 Oct 93 01:04:04 EDT Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17809; Wed, 27 Oct 93 01:04:03 EDT Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11966>; Tue, 26 Oct 1993 22:03:35 PDT Received: by holmes.parc.xerox.com id <16134>; Tue, 26 Oct 1993 22:03:23 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41 via MS.5.6.holmes.parc.xerox.com.sun4_41; Tue, 26 Oct 1993 22:03:21 -0700 (PDT) Message-Id: <0gnU4NMB0KGWJGoJ4=@holmes.parc.xerox.com> Date: Tue, 26 Oct 1993 22:03:21 PDT Sender: Bill Janssen From: Bill Janssen To: Nathaniel Borenstein , Ned Freed Subject: Re: yet another way to indicate related MIME body parts Cc: Keith Moore , ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu In-Reply-To: <01H4JT2QM2608WVZ4V@INNOSOFT.COM> References: <01H4JT2QM2608WVZ4V@INNOSOFT.COM> Yes, this bothered me about multipart/header-set. I had exactly the same reaction as Ned: ``I find all of these proposals to be contrary to what I see as the MIME philosophy''. I'd like to read multipart/related again, though. Bill From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 02:40:00 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18139; Wed, 27 Oct 93 01:53:25 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18135; Wed, 27 Oct 93 01:53:23 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 22:53:00 PST Date: Tue, 26 Oct 1993 22:46:23 -0800 (PST) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Tue, 26 Oct 1993 15:11:04 -0400" <9310261911.AA23268@thud.cs.utk.edu> To: Keith Moore Cc: sdorner@qualcomm.com, ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Message-Id: <01H4L2THEHN88WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > The real question is: is there a need for MIME objects that can reference one > another? I think there is. An application/html document is a single "page", > yet you usually peruse them in sets, and mailing a set of such documents > around seems like a natural thing to do. (Mac users mail around hypercard, > stacks, don't they?) I agree that such a need will soon exist if it doesn't exist already. I'm less confident of multipart/related's ability to fill the bill when such an application does arise. It is tough to anticipate what the future holds in any case, but it is really hard when you're working in advance of *any* deployed application. > At the same time, I don't want mime mail readers to incur the overhead of > copying components of a multipart/references set to separate files, if it's > not needed for that application. We can always have both header-set as well as related. Alternately, we could put a another parameter on header-set to say whether or not the parts reference each other. On the other hand, it seems to me that the subsubtype is enough to tell us whether or not the parts are related, so maybe we should just subsume the semantics of related into header-set. Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 03:10:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18668; Wed, 27 Oct 93 02:19:02 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18664; Wed, 27 Oct 93 02:19:00 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Tue, 26 Oct 1993 23:18:44 PST Date: Tue, 26 Oct 1993 23:13:46 -0800 (PST) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Tue, 26 Oct 1993 11:42:25 -0500" <199310261643.AA11902@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H4L3PE0BEM8WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > I mildly prefer header-set to multipart/foo. I prefer either to > multipart/references without the start parameter, and definitely unprefer > the start parameter. > Header-set has two advantages over multipart/foo. One, the "header" part > is known a priori to be optional, and readers that don't understand it know > that ignoring it is ok (unlike multipart/unknown-foo, which gets treated > like mixed). Interesting notion. Are you sure that readers are justified in ignoring the header parts in things they don't recognize? > Two, by making the header part multipart, you can associate multiple sets of > header info without repeating the data part. The drawback is that you don't > know what the aggregate is until you look inside; for my implementation, this > is no problem at all. As it happens I'd worked out a nice SGML example that used this trick to format a document in different ways, but I never bothered to post it. The other issue that arises here is how to select among the headers. If multipart/alternative semantics are applied you have to read all of them and them pick the last one you are capable of displaying. Are these the semantics we want? > multipart/references (without start) is a bit more complex, and offers no > advantage to what *I* want to do right *now* (AppleDouble). I can see that > it's more powerful, but without some concrete examples of how that power is > going to be used, I can't say it puts the cream in my coffee. I'm having exactly the same problem, myself. > The start parameter is trouble for me. It could force me into using temp > files, something I don't need to do for the other three alternatives. You may find yourself doing this for some sorts of multipart headers as well. Document format information can be pretty large. Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 04:20:06 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19232; Wed, 27 Oct 93 04:00:58 EDT Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19228; Wed, 27 Oct 93 04:00:56 EDT Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA05617; Wed, 27 Oct 93 09:00:44 +0100 Message-Id: <9310270800.AA05617@nada.kth.se> To: Ned Freed Cc: sdorner@qualcomm.com, ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Tue, 26 Oct 1993 23:13:46 PST." <01H4L3PE0BEM8WVZ4V@INNOSOFT.COM> Date: Wed, 27 Oct 1993 09:00:43 +0100 From: Patrik Faltstrom Ned Freed writes: >> Header-set has two advantages over multipart/foo. One, the "header" part >> is known a priori to be optional, and readers that don't understand it know >> that ignoring it is ok (unlike multipart/unknown-foo, which gets treated >> like mixed). > >Interesting notion. Are you sure that readers are justified in ignoring the >header parts in things they don't recognize? One "problem" with this idea of skipping unknown parts is the case of AppleDouble. Example: A user runs a MIME aware mailer, which don't know what to do with this message: multipart/header-set application/applefile image/gif According to the header-set proposal, the first part is skipped and the second is saved to a file and presented to the user. IF the first part was not skipped, the user might have had the opportunity to save the first part as well as the second part, and by naming the files "%picture.gif" and "picture.gif" the user is able to pick up the appledouble file with Fetch for example or any other file transfer software which understands AppleDouble. What I mean is that it is dangerous to "skip and throw away" some parts that the mailer doesn't understand, but the user does. So, what header-set helps the mailer with is to make some more intelligent message to the user than multipart/whatever which is treated as multipart/mixed. Are your ideas that the first part in a header-set multipart always can be skipped, or how should it be treated by the mailer? paf From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 09:07:32 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20281; Wed, 27 Oct 93 09:04:49 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20277; Wed, 27 Oct 93 09:04:47 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA03516; Wed, 27 Oct 93 06:04:39 -0700 Message-Id: <9310271304.AA03516@Mordor.Stanford.EDU> To: Ned Freed Cc: EDI List , ietf-822@dimacs.rutgers.edu Subject: Re: EDI Mime body part Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 26 Oct 93 21:40:51 -0800. <01H4L0DG21Q48WVZ4V@INNOSOFT.COM> Date: Wed, 27 Oct 93 06:04:39 -0700 From: Dave Crocker X-Mts: smtp Ned, Thanks for the proof-reading. You're right about the cut-and-paste error. d/ From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 09:37:36 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20384; Wed, 27 Oct 93 09:17:48 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20380; Wed, 27 Oct 93 09:17:46 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AB11579 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 08:17:18 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA00426 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 27 Oct 1993 08:17:43 -0500 Message-Id: <199310271317.AA00426@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 08:16:32 -0500 To: Patrik Faltstrom , Ned Freed From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: yet another way to indicate related MIME body parts Cc: ietf-822@dimacs.rutgers.edu At 9:00 AM 10/27/93 +0100, Patrik Faltstrom wrote: >So, what header-set helps the mailer with is to make some more >intelligent message to the user than multipart/whatever which >is treated as multipart/mixed. Yes, Patrik's way of stating it is better. "Ignoring" is probably too strong a word. Header-set makes a statement that the first part is additional information, and that the real meat of the part is later. That doesn't necessarily mean that the header part should go irretrievably into the bit-bucket if it isn't understood. Exactly how much difference this distinction makes in practice probably depends on your implementation. Dave Crocker a while ago suggested that when a Mac mailer got an "unknown" (to it) MIME type, it might ask the user what Mac type corresponded to it. For the first part of a header-set, you would probably eschew this behavior. Not an enormous advantage, I guess. -- 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 Wed Oct 27 10:08:35 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20618; Wed, 27 Oct 93 09:30:34 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20613; Wed, 27 Oct 93 09:30:33 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 27 Oct 93 09:30:28 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 27 Oct 93 09:31:19 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; Wed, 27 Oct 1993 09:31:18 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 09:31:18 -0400 (EDT) From: Nathaniel Borenstein To: Keith Moore , Ned Freed Subject: Re: yet another way to indicate related MIME body parts Cc: Ned Freed , sdorner@qualcomm.com, Keith Moore , ietf-822@dimacs.rutgers.edu In-Reply-To: <01H4L1XUM0VA8WVZ4V@INNOSOFT.COM> References: <01H4L1XUM0VA8WVZ4V@INNOSOFT.COM> Excerpts from mail: 26-Oct-93 RE: yet another way to indi.. Ned Freed@INNOSOFT.COM (4854*) > > In a metamail-like environment, it appears that multipart/foo puts a big > > burden on the programs that must interpret such body parts, because > they have > > to be able to parse multipart MIME messages. > I disagree. multipart/foo is either recognized, in which case it is handled by > an appropriate handler that knows what to do, or it isn't, in which case it is > treated as multipart/mixed. In either case the decision is easily made > based on > the existing mailcap facility. The appropriate handler can easily do whatever > it needs to do to the inner parts. Actually, the situation is much BETTER than even Ned implies. Recent versions of metamail have added support to make it much easier for people to write new multipart subtype handlers. In particular, in a mailcap entry for a multipart/foo handler, %n will be replaced by the number of parts within the multipart object. %F will be replaced by a series of arguments, two for each part, giving first the content-type and then the name of the temporary file where the decoded part has been stored. In addition, for each file created by %F, a second file is created, with the same name followed by "H", which contains the header information for that body part. Of course, metamail handles the temp file cleanup after the handler exits. All of this means that, for any value of "foo", you can easily write a multipart/foo handler for metamail without understanding ANY of the details of transfer-encoding or MIME multipart structure! So I think Keith's "burden" is illusory. > So now let's crank through the code and add another squirrel > file (maybe we'll call this one a rabbit file, for variety) to handle this > special case. Yuck! Sigh. The early versions of metamail were probably the cleanest code I ever wrote, because I suspected it would be widely read, and that any ugliness in the code would embarass me for a long time. I was right. I should never have tried to implement multipart/alternative in the main program. Now I'm going to hate rodents for the rest of my life.... From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 10:38:33 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21355; Wed, 27 Oct 93 10:10:41 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21351; Wed, 27 Oct 93 10:10:39 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA12479 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 09:10:09 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA00512 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 27 Oct 1993 09:11:35 -0500 Message-Id: <199310271411.AA00512@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 09:10:22 -0500 To: Ned Freed From: sdorner@qualcomm.com (Steve Dorner) Subject: RE: Re[2]: yet another way to indicate related MIME body parts Cc: ietf-822@dimacs.rutgers.edu At 5:41 PM 10/26/93 -0700, Ned Freed wrote: >Perhaps in most cases the header parameter will be the same as the inner >header's content type, but I don't necessarily see why this needs to be a >requirement. There may be cases where a given multipart construct can have >different sorts of headers. One of the suggested benefits of header-set is to allow alternative headers for data without having to repeat the data. If Ned wants a parameter that tells him what "sort" of header-set it is, and you specify alternative headers, THEN what? multipart/header-set; type=??? multipart/alternative application/applefile application/windows-info image/gif What's ??? ? "file-with-info" (as distinguished from "pem" or something)? Is that enough for you, Ned? Can your implementation solve this problem at all? I know you may want to turn into macbinary to keep Mac All-In-One happy. But is there a Windows version of All-In-One? Do you need to turn it into something else for that? If so, how do you know which transformation to apply? -- 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 Wed Oct 27 11:08:39 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21596; Wed, 27 Oct 93 10:26:52 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21592; Wed, 27 Oct 93 10:26:51 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 27 Oct 93 10:24:42 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for loverso@osf.org; Wed, 27 Oct 93 10:25:33 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; Wed, 27 Oct 1993 10:25:32 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 10:25:32 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: Text/enriched ambiguity Cc: John Robert LoVerso It has been pointed out to me that the specification for text/enriched is unclear about what interpretation is to be given to the data between and . In particular, should such parameters be parsed as text/enriched data? I've gone back and forth on this, but I think what it comes down to is that if we DON'T parse it, we complicate text/enriched parsers as much as the now-discarded "verbatim" did. So I'm thinking of adding the following sentence to the definition of "param": Anything between the initial "" and the terminating "" is subject to normal text/enriched parsing, nesting, etc. Comments, anyone? -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 11:38:36 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21814; Wed, 27 Oct 93 10:38:23 EDT Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21809; Wed, 27 Oct 93 10:38:15 EDT Received: from [192.52.179.3] (conklin-mac.educom.edu) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA16501; Wed, 27 Oct 1993 10:38:05 -0400 Message-Id: <199310271438.AA16501@ivory.educom.edu> Date: Wed, 27 Oct 1993 10:38:19 -0500 To: ietf-822@dimacs.rutgers.edu From: conklin@ivory.educom.edu (Jim Conklin) X-Sender: conklin@educom.edu Subject: RE: yet another way to indicate related MIME body parts If one is using MIME to pass around material in which there's considerable internal structure, such as Hypercard stacks or HTML (for example), why isn't it better to register and use the specific application rather than to try to make MIME itself handle that level of complexity? Jim From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 15:36:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29130; Wed, 27 Oct 93 15:05:39 EDT Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29123; Wed, 27 Oct 93 15:05:35 EDT Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA12777; Wed, 27 Oct 93 15:05:19 -0400 Message-Id: <9310271905.AA12777@thud.cs.utk.edu> From: Keith Moore To: conklin@ivory.educom.edu (Jim Conklin) 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 "Wed, 27 Oct 1993 10:38:19 CDT." <199310271438.AA16501@ivory.educom.edu> Date: Wed, 27 Oct 1993 15:05:17 -0400 Sender: moore@cs.utk.edu > If one is using MIME to pass around material in which there's > considerable internal structure, such as Hypercard stacks or HTML (for > example), why isn't it better to register and use the specific application > rather than to try to make MIME itself handle that level of complexity? I don't know enough about Hypercard stacks to answer the question for that case. But people talk about them as if hypercard thingys are shipped around in "stacks", with an internal structure that's specific to Hypercard. I've never heard anyone talk about ftp-ing a single Hypercard page. So maybe it makes sense to ship around a whole hypercard stack as a single MIME object. HTML documents are normally addressed per-document, and copied around one document at a time. Given that such documents can stand by themselves and be understood by MIME at that level, it makes sense to use MIME strucutre for sets of HTML documents. (but the HTML guys may have a different idea. any of them listening?) Keith From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 16:06:57 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29454; Wed, 27 Oct 93 15:26:23 EDT Received: from relay2.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29450; Wed, 27 Oct 93 15:26:22 EDT From: beyond!eng!tcrowley@uunet.uu.net Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA13754; Wed, 27 Oct 93 15:26:20 -0400 Received: from beyond.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 152415.17881; Wed, 27 Oct 1993 15:24:15 EDT Received: by beyond.UUCP Wed, 27 Oct 93 15:15:35 EDT Message-Id: <7C9CCE2C01842879@beyond.UUCP> Date: Wed, 27 Oct 93 15:15:35 EDT To: , Subject: Re: Text/enriched ambiguity X-Mailer: UGate [Ver. 1.65] >> It has been pointed out to me that the specification for text/enriched >> is unclear about what interpretation is to be given to the data between >> and . In particular, should such parameters be parsed >> as text/enriched data? I've gone back and forth on this, but I think >> what it comes down to is that if we DON'T parse it, we complicate >> text/enriched parsers as much as the now-discarded "verbatim" did. So >> I'm thinking of adding the following sentence to the definition of >> "param": >> Anything between the initial "" and the terminating "" is >> subject to normal text/enriched parsing, nesting, etc. Isn't this ambiguity inherent in the two different uses of extensions? That is, one use is to change the attributes of the text in between the parameter (e.g. your color example) and one is to include additional information/data that should not be parsed (e.g. a color table that is then used by another extension to reference colors by index). Seems like both capabilities are necessary - the extension facility should provide for both uses. On the other hand (am I out of hands?) you clearly need to address the parsing complexity issue. Perhaps the way to address the data problem is to force it into standard enriched syntax, so you have: vs. colorentry 0 255 255 0> colorentry 1 0 255 0> This places size restrictions on how the data can be organized, but perhaps that's worth the trouble to restrict the parsing headaches. Yet another compromise would be to be able to include the data as in my second example (that is, its plain text but doesn't appear in the normal textual output) but require that it be parsable as standard enriched text. This seems like the best approach. That means that you still have to come up with a syntax for differentiating whether an extension should include or exclude embedded text. Terry From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 16:36:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29983; Wed, 27 Oct 93 16:05:47 EDT Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29975; Wed, 27 Oct 93 16:05:41 EDT Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19396; Wed, 27 Oct 93 21:05:27 +0100 Message-Id: <9310272005.AA19396@nada.kth.se> To: Keith Moore Cc: conklin@ivory.educom.edu (Jim Conklin), ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Wed, 27 Oct 1993 15:05:17 -0400." <9310271905.AA12777@thud.cs.utk.edu> Date: Wed, 27 Oct 1993 21:05:25 +0100 From: Patrik Faltstrom Keith Moore writes: >I don't know enough about Hypercard stacks to answer the question for that >case. But people talk about them as if hypercard thingys are shipped around >in "stacks", with an internal structure that's specific to Hypercard. I've >never heard anyone talk about ftp-ing a single Hypercard page. So maybe it >makes sense to ship around a whole hypercard stack as a single MIME object. That's correct. Nothing says that a script on a separate hypercard card will work without the stack, i.e. copied into another stack. A Hypercard stack will only work as one document, i.e. preferrable as a Macintosh document. It can include 68k code in the recource fork also, i.e. compiled C-code which can be called from the script in the stack. Because of that a stack must be treated even as a Macintosh application and not only as a document with a data fork only. Patrik From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 17:06:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00105; Wed, 27 Oct 93 16:06:42 EDT Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00101; Wed, 27 Oct 93 16:06:41 EDT Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Wed, 27 Oct 93 16:06:24 EDT Received: by guppylake.bellcore.com (4.1/4.7) id for loverso@osf.org; Wed, 27 Oct 93 16:07:15 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; Wed, 27 Oct 1993 16:07:14 -0400 (EDT) Message-Id: Date: Wed, 27 Oct 1993 16:07:14 -0400 (EDT) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity Cc: loverso@osf.org In-Reply-To: <7C9CCE2C01842879@beyond.UUCP> References: <7C9CCE2C01842879@beyond.UUCP> Excerpts from mail: 27-Oct-93 Re: Text/enriched ambiguity tcrowley@uunet.UU.NET (2022) > On the other hand (am I out of hands?) you clearly need to address the > parsing complexity issue. Perhaps the way to address the data problem is to > force it into standard enriched syntax Hmm, this would also require adding a rule about how to tell where a command name ends & parameters begin, presumably just using spaces or something like that. Then we'd probably effectively be saying that is equivalent to , and so on. We'd have to address the problem of how to treat recognized commands with unrecognized parameters, but we probably get simplified parsing overall. Any other opinions? From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 17:36:58 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00608; Wed, 27 Oct 93 16:50:53 EDT Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00604; Wed, 27 Oct 93 16:50:50 EDT Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Thu, 28 Oct 93 06:50:39 +1000 Date: Thu, 28 Oct 93 06:50:38 EST From: rhys@cs.uq.oz.au Message-Id: <9310272050.AA05869@client> To: NED@sigurd.innosoft.com, sdorner@qualcomm.com Subject: RE: Re[2]: yet another way to indicate related MIME body parts Cc: ietf-822@dimacs.rutgers.edu >What's ??? ? "file-with-info" (as distinguished from "pem" or something)? >Is that enough for you, Ned? I suggest a comma-separated list of subtypes if there is an alternative in the header-set's first body part. Otherwise we will have to register new pseudo-subtypes for "file-with-info" and other such gadgets, which I don't like because it brings the lookahead back: "is this a Mac or a Windows 'file-with-info', or is it someone else's?". >Can your implementation solve this problem at all? I know you may want to >turn into macbinary to keep Mac All-In-One happy. But is there a Windows >version of All-In-One? Do you need to turn it into something else for >that? If so, how do you know which transformation to apply? I can't comment on All-In-One (never used it). I will say that Windows does have file header info in some cases. The one that comes to mind is OLE (Object Linking and Embedding) files which have some header info (class name, topic name, network machine name, and other stuff) and then the data itself. If I was sending an OLE object via MIME, I'd want to split the header info off so that non-Windows user agents can get at the raw data, yet still be able to rebuild the OLE object in a Windows user agent so it can be linked into an application on the recipient's machine. So, header-set or some equivalent is looking very attractive to me. It's also possible that some or all of the OLE header info could be translated into the Mac AppleSingle information given a suitably smart MIME user agent, so having the ability to do alternatives in the first body part would be a plus. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 18:13:34 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02981; Wed, 27 Oct 93 17:55:44 EDT Received: from inet-gw-2.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02977; Wed, 27 Oct 93 17:55:43 EDT Received: by inet-gw-2.pa.dec.com; id AA15056; Wed, 27 Oct 93 14:55:40 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA16921 for ietf-822@dimacs.rutgers.edu; Wed, 27 Oct 93 17:55:36 -0400 Message-Id: <9310272155.AA16921@skidrow.lkg.dec.com> To: ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Wed, 27 Oct 93 15:05:17 EDT." <9310271905.AA12777@thud.cs.utk.edu> Date: Wed, 27 Oct 93 17:55:36 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Keith Moore To: conklin@ivory.educom.edu (Jim Conklin) Cc: ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu In-Reply-To: Your message of "Wed, 27 Oct 1993 10:38:19 CDT." <199310271438.AA16501@ivory.educom.edu> Sender: moore@cs.utk.edu >> If one is using MIME to pass around material in which there's >> considerable internal structure, such as Hypercard stacks or HTML (for >> example), why isn't it better to register and use the specific application >> rather than to try to make MIME itself handle that level of complexity? > >I don't know enough about Hypercard stacks to answer the question for that >case. But people talk about them as if hypercard thingys are shipped around >in "stacks", with an internal structure that's specific to Hypercard. I've >never heard anyone talk about ftp-ing a single Hypercard page. So maybe it >makes sense to ship around a whole hypercard stack as a single MIME object. I believe the internal structure of Hypercard stacks is an Apple trade secret. Donald From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 18:36:57 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03112; Wed, 27 Oct 93 18:13:10 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03106; Wed, 27 Oct 93 18:13:05 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA25840 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 17:12:38 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01520 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 27 Oct 1993 17:13:59 -0500 Message-Id: <199310272213.AA01520@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 17:13:20 -0500 To: rhys@cs.uq.oz.au, NED@sigurd.innosoft.com From: sdorner@qualcomm.com (Steve Dorner) Subject: RE: Re[2]: yet another way to indicate related MIME body parts Cc: ietf-822@dimacs.rutgers.edu At 6:50 AM 10/28/93 -0500, rhys@cs.uq.oz.au wrote: >I suggest a comma-separated list of subtypes if there is an alternative >in the header-set's first body part. No objection from this quarter. -- 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 Wed Oct 27 19:06:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03116; Wed, 27 Oct 93 18:13:13 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03108; Wed, 27 Oct 93 18:13:07 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA25841 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 17:12:38 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01523 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 27 Oct 1993 17:14:05 -0500 Message-Id: <199310272214.AA01523@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 17:13:26 -0500 To: Patrik Faltstrom , Keith Moore From: sdorner@qualcomm.com (Steve Dorner) Subject: Re: yet another way to indicate related MIME body parts Cc: conklin@ivory.educom.edu (Jim Conklin), ietf-822@dimacs.rutgers.edu At 9:05 PM 10/27/93 +0100, Patrik Faltstrom wrote: >That's correct. Nothing says that a script on a separate hypercard card >will work without the stack, i.e. copied into another stack. Except that stacks can reference other stacks via a sorta-hypertext mechanism, so you could in fact have a single "master" stack that referenced a bunch of satellite stacks. This is really not unlike HTML. -- 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 Wed Oct 27 19:36:57 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03595; Wed, 27 Oct 93 19:24:08 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03589; Wed, 27 Oct 93 19:24:06 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H4LZ4F4BK0934SNW@SIGURD.INNOSOFT.COM>; Wed, 27 Oct 1993 16:23:54 PDT Date: Wed, 27 Oct 1993 16:21:09 -0700 (PDT) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Wed, 27 Oct 1993 17:13:20 -0500" <199310272213.AA01520@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: rhys@cs.uq.oz.au, NED@sigurd.innosoft.com, ietf-822@dimacs.rutgers.edu Message-Id: <01H4M3IF9TFO934SNW@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > > I suggest a comma-separated list of subtypes if there is an alternative > > in the header-set's first body part. > No objection from this quarter. As long as we're going to commit to having the subtypes of the header-set match what's in the multipart parameter, I have no problem with this either. I still question whether or not requiring the parameter to be the same as the header set type isn't overly restrictive in the long term. But then again, I would much rather flush all these proposals completely and go back to multipart/foo, so who am I to say what relation should exist? Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 20:10:53 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03513; Wed, 27 Oct 93 19:18:10 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03508; Wed, 27 Oct 93 19:18:07 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H4LZ4F4BK0934SNW@SIGURD.INNOSOFT.COM>; Wed, 27 Oct 1993 16:17:41 PDT Date: Wed, 27 Oct 1993 16:09:32 -0700 (PDT) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Wed, 27 Oct 1993 09:10:22 -0500" <199310271411.AA00512@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: Ned Freed , ietf-822@dimacs.rutgers.edu Message-Id: <01H4M3AOTHNO934SNW@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > One of the suggested benefits of header-set is to allow alternative headers > for data without having to repeat the data. If Ned wants a parameter that > tells him what "sort" of header-set it is, and you specify alternative > headers, THEN what? The parameter gives me the broad outlines of what the collective data represent. > multipart/header-set; type=??? > multipart/alternative > application/applefile > application/windows-info > image/gif I don't see this as a viable use of this concept. Something like multipart/header-set; type=appledouble multipart/alternative application/applefile application/altnertive-packaging-of-apple-file-information image/gif would be as close as I can come to a use of multipart in the appledouble case. > What's ??? ? "file-with-info" (as distinguished from "pem" or something)? > Is that enough for you, Ned? Nope. It isn't enough. I require that the multipart type identify what's going on before I have to process the first part. Nothing less is acceptable to me. > Can your implementation solve this problem at all? I know you may want to > turn into macbinary to keep Mac All-In-One happy. The ALL-IN-1 example is just an example. It isn't even a very important example. I have dozens of other gateway components to think about here besides ALL-IN-1, and frankly appledouble is the least of my worries when it comes to gateway considerations. The other uses of header-set worry me a heck of a lot more. > But is there a Windows version of All-In-One? As a matter of fact there is -- sort of. > Do you need to turn it into something else for that? Yes indeed. That's why a packaging more along the lines of multipart/alternative multipart/header-set; type=appledouble application/applefile image/gif image/tiff would be what I'd expect in this case. > If so, how do you know which transformation to apply? Either I'm told by a configuration file what to do or I have to do all of them. In either case I want to know what's going in the structure before I have to commit to any single approach. Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 20:36:58 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03888; Wed, 27 Oct 93 20:00:01 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03882; Wed, 27 Oct 93 20:00:00 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA16350; Wed, 27 Oct 93 16:59:38 -0700 Message-Id: <9310272359.AA16350@Mordor.Stanford.EDU> To: Ned Freed Cc: sdorner@qualcomm.com, rhys@cs.uq.oz.au, ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: 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 Wed, 27 Oct 93 16:21:09 -0700. <01H4M3IF9TFO934SNW@SIGURD.INNOSOFT.COM> Date: Wed, 27 Oct 93 16:59:38 -0700 From: Dave Crocker X-Mts: smtp in the matter of header-set (or whatever) having a parameter that lists the sub-types. How should sub-structure (e.g., the multiple headers inside an alternate) be represented? d/ From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 21:46:19 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03999; Wed, 27 Oct 93 20:20:58 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03994; Wed, 27 Oct 93 20:20:56 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA28169 (5.67a/IDA-1.5 for ); Wed, 27 Oct 1993 19:20:32 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA01700 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Wed, 27 Oct 1993 19:22:10 -0500 Message-Id: <199310280022.AA01700@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Oct 1993 19:21:31 -0500 To: ietf-822@dimacs.rutgers.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: RE: Re[2]: yet another way to indicate related MIME body parts At 4:09 PM 10/27/93 -0700, Ned Freed wrote: >Yes indeed. That's why a packaging more along the lines of > > multipart/alternative > multipart/header-set; type=appledouble > application/applefile > image/gif > image/tiff > >would be what I'd expect in this case. But this misses the point of header-set. The point is that you do NOT have to repeat the image. If I can (please) take the liberty of changing that "tiff" to "gif", the idea behind header-set is to allow you to express your example like: multipart/header-set; type=appledouble application/applefile image/gif The image is transmitted only once. Or, to return to my original example, we have: mp/h-s; t=applefile,windows-info multipart/alternative mp/alternative mp/appledouble application/applefile vs application/applefile application/windows-info image/gif image/gif mp/windowsdouble application/windows-info image/gif As I see it, header-set has three advantages: 1. It eliminates the need to register a subtype of multipart for each multipart thing. 2. By making the first part alternative, you can associate several different headers with one set of data, saving the multiple retransmission of the data. 3. The reader has a hint that the header part of the header-set is not the essential data. (Though PEM makes me uneasy on this score.) Now, requiring a "type=" parameter on the header-set header largely negates advantage 1, in my view. Spade a spade, rose by any other name, etc, etc. Forbidding an alternative for the header part and instead using an outer alternative construct completely negates advantage 2. Advantage 3 is pretty minor and questionable. So, if we accept Ned's restrictions on header-set, I'm not sure that header-set does any good; we may as well just use multipart/foo. That isn't a disaster as far as I'm concerned; I thought header-set was a nifty idea, but I don't really mind having lots of multipart subtypes, either. -- 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 Wed Oct 27 22:06:59 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07856; Wed, 27 Oct 93 21:28:54 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07852; Wed, 27 Oct 93 21:28:52 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H4LZ4F4BK0934SNW@SIGURD.INNOSOFT.COM>; Wed, 27 Oct 1993 18:28:35 PDT Date: Wed, 27 Oct 1993 18:16:32 -0700 (PDT) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Wed, 27 Oct 1993 09:00:43 +0100" <9310270800.AA05617@nada.kth.se> To: Patrik Faltstrom Cc: Ned Freed , sdorner@qualcomm.com, ietf-822@dimacs.rutgers.edu Message-Id: <01H4M7V0PEA0934SNW@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > ... > So, what header-set helps the mailer with is to make some more > intelligent message to the user than multipart/whatever which > is treated as multipart/mixed. I'm afraid I don't see the point. You have now argued, quite successfully as far as I can see, that it is dangerous for a reader to treat multipart/header-set with an unrecognized initial header part in any special way. In other words, it should be treated as multipart/mixed if the header set isn't known. But how does this differ from handling of multipart/whatever would get? > Are your ideas that the first part in a header-set multipart > always can be skipped, or how should it be treated by the mailer? multipart/header-set claims to solve some kind of problem by making it known that the first part is somehow special. Fine. Now, a given system either knows how to handle this special sort of entity (whatever it might be, however it is labelled) or it doesn't. And if the structure is understood the particulars of the labelling are not relevant. This means that the only case that distinguishes multipart/header-set from multipart/whatever is the one where the header isn't recognized. So, I'm therefore asking what I see as a very reasonable question: How does the handling of multipart/header-set differ from the handling of multipart/whatever when the header isn't recognized? Thus far I have seen only one explanation of how the handling might differ, which you just got finished showing is a bad idea. Until and unless I see some tangible reason why the semantics of a header-set are useful to someone, somewhere, I will continue to see no point in this proposal. I can live with it with the added parameter, but I still don't think it is useful. Ned From owner-ietf-822@dimacs.rutgers.edu Wed Oct 27 21:06:58 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03722; Wed, 27 Oct 93 19:42:18 EDT Received: from SIGURD.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA03717; Wed, 27 Oct 93 19:42:13 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H4LZ4F4BK0934SNW@SIGURD.INNOSOFT.COM>; Wed, 27 Oct 1993 16:42:02 PDT Date: Wed, 27 Oct 1993 16:28:58 -0700 (PDT) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Wed, 27 Oct 1993 15:05:17 -0400" <9310271905.AA12777@thud.cs.utk.edu> To: Keith Moore Cc: conklin@ivory.educom.edu, ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Message-Id: <01H4M45VEIDS934SNW@SIGURD.INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > > If one is using MIME to pass around material in which there's > > considerable internal structure, such as Hypercard stacks or HTML (for > > example), why isn't it better to register and use the specific application > > rather than to try to make MIME itself handle that level of complexity? > I don't know enough about Hypercard stacks to answer the question for that > case. But people talk about them as if hypercard thingys are shipped around > in "stacks", with an internal structure that's specific to Hypercard. I've > never heard anyone talk about ftp-ing a single Hypercard page. So maybe it > makes sense to ship around a whole hypercard stack as a single MIME object. This is all very dependent on the application you are talking about as well as how it represents its data on the platforms where it is used. Quite a large number of applicatios use a single file on all platforms. (Sometimes the format is the same everywhere, in other cases unfortunately it isn't.) In this case there's no point in breaking out the components of the file into separate parts in a multipart structure. Other applications use groups of files. (This is true of many markup languages, for example.) In this case it may make a lot of sense to put each of the components inside of a multipart/related object. Most such applications are inherently multi-file and don't provide a way to package up all their components in a single bundle. (The only format I know of that has such a packaging scheme is DDIF and its DOTS packages.) And then there are things that lie in between the two extremes. Appledouble, for example, is the way it is because Macintosh files are multipart entities, and the data part is meaningful by itself on non-Mac platforms. (I suspect that Windows NT will give rise to some interesting variations eventually, since its files can contain an arbitrary number of separate "forks".) In the final analysis it is all a matter of thinking through the engineering tradeoffs. Monolithic object formats have their place, as do sophisticated uses of MIME multipart objects. Ned From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 02:37:00 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09877; Thu, 28 Oct 93 02:31:16 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09873; Thu, 28 Oct 93 02:31:11 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Wed, 27 Oct 1993 23:30:44 PST Date: Wed, 27 Oct 1993 23:09:14 -0800 (PST) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Wed, 27 Oct 1993 19:21:31 -0500" <199310280022.AA01700@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H4MIFLFVNE8WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > But this misses the point of header-set. The point is that you do NOT have > to repeat the image. If I can (please) take the liberty of changing that > "tiff" to "gif", the idea behind header-set is to allow you to express your > example like: > ... Well, this is all news to me. There isn't anything even resembling such a goal in the header-set draft I have read. This appears to be a recent invention that has been brought in to justify header-set now that it has failed demonstrate any other advantages. If the goal of header-set is to reduce the size of the data we have to transfer around, then it needs to be reevaluated in that light. There are plenty of other approaches (compression, external references, etc.) that reduce message sizes. It is far from clear that header-set is the right solution, or even a solution, to these problems. > ... > As I see it, header-set has three advantages: > 1. It eliminates the need to register a subtype of multipart for each > multipart thing. Let's see. For each header-set header, you have to register a type, right? Where's the huge overhead involved in registering a subtype of multipart at the same time? I see no overhead here at all! I'm sorry, but this is nothing short of a complete red herring. > 2. By making the first part alternative, you can associate several > different headers with one set of data, saving the multiple retransmission > of the data. This quite clearly is not what header-set was designed to do. I am very troubled to find that the stated goals of all this work seem to be completely mutable over time. This is not good engineering. Either header-set stands on the merits set forth in its documentation or that document needs to be withdrawn and replaced with another document that does state what the goals are. Once the goals are stated people can discuss them intelligently and possibly propose useful alternatives. > 3. The reader has a hint that the header part of the header-set is not the > essential data. (Though PEM makes me uneasy on this score.) Every single header-set type currently under discussion makes me *very* uneasy on this score. Doesn't this sound like a trend to you? > Now, requiring a "type=" parameter on the header-set header largely negates > advantage 1, in my view. Spade a spade, rose by any other name, etc, etc. Simple question: Why? Let's say that we adopt the simplest possible header-set mechanism with a parameter, where there's simply a list of the header types in the outer multipart content-type. Does this present any problems to any implementation? I cannot see how it does. Does this present any problems for header registration? I sure don't see any. Does this present any problems in any other areas? None that I'm aware of. > Forbidding an alternative for the header part and instead using an outer > alternative construct completely negates advantage 2. Strawman argument here. Nobody ever suggested banning multipart/alternative for headers. I simply suggested that it might not be appropriate for appledouble. > Advantage 3 is pretty minor and questionable. I see them all as highly dubious. > So, if we accept Ned's restrictions on header-set, I'm not sure that > header-set does any good; we may as well just use multipart/foo. That > isn't a disaster as far as I'm concerned; I thought header-set was a nifty > idea, but I don't really mind having lots of multipart subtypes, either. OK by me. I've yet to see anything but lots of pain and absolutely no gain in all this header-set stuff. Ned From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 03:07:01 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09892; Thu, 28 Oct 93 02:38:15 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09888; Thu, 28 Oct 93 02:38:14 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Wed, 27 Oct 1993 23:37:34 PST Date: Wed, 27 Oct 1993 23:31:50 -0800 (PST) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Wed, 27 Oct 1993 16:59:38 -0700" <9310272359.AA16350@Mordor.Stanford.EDU> To: Dave Crocker Cc: Ned Freed , sdorner@qualcomm.com, rhys@cs.uq.oz.au, ietf-822@dimacs.rutgers.edu Message-Id: <01H4MIO2RD428WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > in the matter of header-set (or whatever) having a parameter that lists the > sub-types. > How should sub-structure (e.g., the multiple headers inside an alternate) > be represented? Quoted comma-separated list would be my choice. It makes me sad that we didn't allow for nested parameter structures in content-type information, but as I recall the one proposal to do that was shot down as being too complex. (This isn't the first time we've needed this capability and I seriously doubt that it will be the last.) Ned P.S. Apologies if my tone is strong this evening -- it may have something to do with watching lots of LA burn to a cinder around me. From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 06:07:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10613; Thu, 28 Oct 93 06:02:31 EDT Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10609; Thu, 28 Oct 93 06:02:29 EDT Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA27987; Thu, 28 Oct 93 11:01:52 +0100 Message-Id: <9310281001.AA27987@nada.kth.se> To: Ned Freed Cc: Ned Freed , sdorner@qualcomm.com, ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Wed, 27 Oct 1993 18:16:32 MST." <01H4M7V0PEA0934SNW@SIGURD.INNOSOFT.COM> Date: Thu, 28 Oct 1993 11:01:51 +0100 From: Patrik Faltstrom Ned Freed writes: >> So, what header-set helps the mailer with is to make some more >> intelligent message to the user than multipart/whatever which >> is treated as multipart/mixed. > >I'm afraid I don't see the point. You have now argued, quite successfully as >far as I can see, that it is dangerous for a reader to treat >multipart/header-set with an unrecognized initial header part in any special >way. In other words, it should be treated as multipart/mixed if the header set >isn't known. But how does this differ from handling of multipart/whatever >would get? I might have to rewrite the sentence once more. As you know english is not my first language (it's swedish 8^) so: That is exactly my point. I can (still) not see what multipart/header-set is "better" than multipart/foo. The only difference is that IF you use header-set, you can hint the user about the fact that he really need to have knowledge about the first part, otherwise it's just a header which is followed by the actual data. The header can NOT be skipped. It must be treated as multipart/mixed. So, then you have a known multipart type, header-set, which has a sub-part which is unknown, then the multipart message should be treated as a multipart/mixed message. This is a very strange way of doing things I think. I thought I should be convinced to use header-set, and like it, see the benefits, but when reading all messages on this list, I now more and more like multipart/foo instead. >Until and unless I see some tangible reason why the semantics of a header-set >are useful to someone, somewhere, I will continue to see no point in this >proposal. I can live with it with the added parameter, but I still don't think >it is useful. I agree. Patrik From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 10:37:05 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12581; Thu, 28 Oct 93 10:22:34 EDT Received: from sun2.nsfnet-relay.ac.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12577; Thu, 28 Oct 93 10:22:32 EDT Via: uk.ac.edinburgh.castle; Thu, 28 Oct 1993 14:21:46 +0000 Received: from ml0.ucs.ed.ac.uk by castle.ed.ac.uk id aa11828; 28 Oct 93 14:20 GMT Received: From UCS-ML0/WORKQUEUE by gold.ucs.ed.ac.uk via Charon-4.0-VROOM with IPX id 100.931028142149.480; 28 Oct 93 14:20:54 +500 Message-Id: To: moore@cs.utk.edu, ietf-822@dimacs.rutgers.edu From: Chris Adie Date: 28 Oct 93 14:21:38 GMT Subject: Re: comments on SHAVE Reply-To: C.J.Adie@edinburgh.ac.uk Priority: normal X-Mailer: Pegasus Mail v2.3 (R5). Keith Moore writes: [....] > It appears that if I want to design an application using SHAVE, I have > to know enough SGML to write a DTD. That's right. One of the main advantages of using SGML for this sort of application is that the DTD is a formal way of describing the legal syntax, such that a document or body part can be automatically validated. We don't want to loose sight of that capability. > 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. I guess there's not too much difference between this kind of parser and what I call a "naive" parser (which does understand something about the application, but perhaps not very much). > 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.) I just tried + % / with sgmls - it doesn't like any of them. The dot is the only non-alphameric I've seen used in element names. I guess we could use .t, .pv and .tt suffixes instead. > 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. Yes, this would certainly be a good way to describe it - in fact, it would be better than the current "restriction rules" method. > 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. It should be possible to create a specification language which is: * easy to describe * easy to write in * easy to convert to a 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? Pick a number and set the NAMELEN to that value in the SGML declaration (which in the current draft is implicit in SHAVE rules 1 & 2). > + 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?) Or an SGML attribute on the element. > + 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). True. This is a consequence of requiring all tags to occur at the start of a line (except for white space). I guess we could change it to recognise two newlines as meaning \r\n at the end of a value. Regards, Chris Adie From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 11:07:05 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12926; Thu, 28 Oct 93 11:00:56 EDT Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12922; Thu, 28 Oct 93 11:00:51 EDT Received: from [192.52.179.3] (conklin-mac.educom.edu) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA21048; Thu, 28 Oct 1993 11:00:23 -0400 Message-Id: <199310281500.AA21048@ivory.educom.edu> Date: Thu, 28 Oct 1993 11:00:39 -0500 To: sdorner@qualcomm.com, Ned Freed From: conklin@ivory.educom.edu (Jim Conklin) X-Sender: conklin@educom.edu Subject: RE: Re[2]: yet another way to indicate related MIME body parts Cc: ietf-822@dimacs.rutgers.edu > I suggest a comma-separated list of subtypes if there is an alternative > in the header-set's first body part. > A bit of human-factors input... I'm regularly using Eudora now, and I ruin my addresses periodically by hitting the period instead of the comma between addresses. I'll bet I'm not alone... It would be nice if the standards could help reduce this kind of problem, which I realize may be nontrivial. But when possible, having the standards accept a period OR a comma, for example, would be nice from the human-factors perspective. As contrasted to the dramatically different meanings of those two characters in addresses. And, yes, I also realize that if I weren't so lazy and would use a comma PLUS a space when typing addresses, I'd have less trouble when I hit a period! ;-) Jim From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 11:37:06 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12905; Thu, 28 Oct 93 10:57:42 EDT Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12901; Thu, 28 Oct 93 10:57:40 EDT Received: from rita-blanca.is.rice.edu by is.rice.edu (AA09746); Thu, 28 Oct 93 09:57:37 CDT Received: by rita-blanca.is.rice.edu (AA02068); Thu, 28 Oct 93 09:57:36 CDT Date: Thu, 28 Oct 1993 09:51:14 -0500 (CDT) From: Rick Troth Subject: Re: yet another way to indicate related MIME body parts To: Ed Levinson Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9310261513.AA16386@Accurate.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > A design goal (unstated naturally ;-) of the mime-sgml proposal is to > be able to use existing, MIME ignorant, software to do the SGML > processing. I know that a lot of us share this goal. All too often it goes without mention. Can we maybe "push" it a bit? > There has to be some middleware software that understands > enough SGML to rebind the MIME parts to the receiver's file system names. > I can see how to do this in a number of ways; I intend to build the > middleware using the existing MIME software; the middleware is, in > part, a MIME UA that just stores the body parts and then invokes the > "real" application. Right. And for other applications there may be more involved. You might be making temporary directories, not just temporary files. But any time we can use non-MIME (eg: preexisting, thus separately maintained) software to do some of the work we get a big win. > Ed -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 12:07:06 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13028; Thu, 28 Oct 93 11:17:08 EDT Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13024; Thu, 28 Oct 93 11:17:06 EDT Received: from rita-blanca.is.rice.edu by is.rice.edu (AA10225); Thu, 28 Oct 93 10:17:04 CDT Received: by rita-blanca.is.rice.edu (AA02085); Thu, 28 Oct 93 10:17:02 CDT Date: Thu, 28 Oct 1993 10:15:19 -0500 (CDT) From: Rick Troth Subject: Re: yet another way to indicate related MIME body parts To: ietf-822@dimacs.rutgers.edu In-Reply-To: <199310261643.AA11902@dorner.slip.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Could someone send me some example multipart/headerset? Send it to troth@vm.rice.edu, or I'll have to risk whichever UNIX MUA du jour clobbering it when I forward it to VM. Thanks! -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 12:37:07 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12988; Thu, 28 Oct 93 11:10:38 EDT Received: from Princeton.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12979; Thu, 28 Oct 93 11:10:37 EDT Received: from acupain.UUCP by Princeton.EDU (5.65b/2.103/princeton) id AA29713; Thu, 28 Oct 93 10:45:24 -0400 Received: from localhost by Accurate.COM (4.1/SMI-4.0) id AA13530; Thu, 28 Oct 93 09:58:35 EDT Message-Id: <9310281358.AA13530@Accurate.COM> To: Ned Freed Cc: Keith Moore , conklin@ivory.educom.edu, ietf-822@dimacs.rutgers.edu Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: Your message of "Wed, 27 Oct 93 16:28:58 PDT." <01H4M45VEIDS934SNW@SIGURD.INNOSOFT.COM> Organization: Accurate Information Systems, Inc. X-Mailer: MH 6.7 Date: Thu, 28 Oct 93 09:58:34 -0400 From: "Ed Levinson" Ned, > Other applications use groups of files. (... markup languages, > for example.) In this case it may make a lot of sense to put each of the > components inside of a multipart/related object. SGML is a good example of "groups of files". In the I-D on sgml the proposal is to use Multipart/SGML, have the first part be the main document, use a Content-reference: header to match body parts to internally referenced file names. It is not clear to me that headerset or references is a simplification. > Most ... don't provide a way to package up all their > components in a single bundle. (The only format I know of ... > is DDIF and its DOTS packages.) SGML has a packaging scheme too, SDIF. Don't know if anyone uses it. Ed > And then there are things that lie in between the two extremes. Appledouble, > for example, is the way it is because Macintosh files are multipart entities, > and the data part is meaningful by itself on non-Mac platforms. (I suspect th at > Windows NT will give rise to some interesting variations eventually, since it s > files can contain an arbitrary number of separate "forks".) > > In the final analysis it is all a matter of thinking through the engineering > tradeoffs. Monolithic object formats have their place, as do sophisticated us es > of MIME multipart objects. > > Ned From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 15:07:08 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18878; Thu, 28 Oct 93 15:05:47 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18874; Thu, 28 Oct 93 15:05:44 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08869; Thu, 28 Oct 93 12:05:39 -0700 Message-Id: <9310281905.AA08869@Mordor.Stanford.EDU> To: Ned Freed Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: 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 Wed, 27 Oct 93 23:09:14 -0800. <01H4MIFLFVNE8WVZ4V@INNOSOFT.COM> Date: Thu, 28 Oct 93 12:05:39 -0700 From: Dave Crocker X-Mts: smtp Ned, ---- Included message: > But this misses the point of header-set. The point is that you do NOT ha ve > to repeat the image. If I can (please) take the liberty of changing that > "tiff" to "gif", the idea behind header-set is to allow you to express yo ur > example like: > ... Well, this is all news to me. There isn't anything even resembling such a g oal in the header-set draft I have read. This appears to be a recent invention Yes. Sorry about that. The version of the spec listed in the internet-drafts directory does not include this text. Due to the closeness of the Houston IETF, I could not post an update quickly enough. It is certainly true that I had not seen this particular benefit of header-set. Amanda Walker suggested it during the recent discussions for Mime content-types for the Mac. that has been brought in to justify header-set now that it has failed demonstrat e any other advantages. This, of course, is not a helpful line of commentary. It would appear that the southern california flames are trying to trigger a brushfire on this list. Rather than a desperate effort to jockey for legitimacy, I tend to see this admittedly-new use for header-set as fall-out which is typically representative of good design. (There might even be a smiley face here.) In any event, I think that Steve Dorner has done a perfect job of summarizing the benefits of header-set, so far, and it is only a matter of whether there is any sort of consensus that those benefits are sufficient. > 1. It eliminates the need to register a subtype of multipart for each > multipart thing. Let's see. For each header-set header, you have to register a type, right? Where's the huge overhead involved in registering a subtype of multipart at the same time? I see no overhead here at all! I'm sorry, but this is nothing short of a complete red herring. I don't understand such trivialization of concern for administrative overhead. We are already experiencing problems and questions about Mime content-type administration; I would think that an effort to greatly reduce one portion of consumption would meet with some warmth, rather than such heat. d/ From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 20:07:08 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20906; Thu, 28 Oct 93 20:02:00 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20902; Thu, 28 Oct 93 20:01:54 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H4NP89DM1S000SQQ@INFOODS.UNU.EDU>; Thu, 28 Oct 1993 20:01:12 EDT Date: Thu, 28 Oct 1993 20:01:11 -0400 (EDT) From: John C Klensin Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: <9310281358.AA13530@Accurate.COM> To: elevinso@accurate.com Cc: NED@sigurd.innosoft.com, moore@cs.utk.edu, conklin@ivory.educom.edu, ietf-822@dimacs.rutgers.edu Message-Id: <751852871.733319.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: > SGML has a packaging scheme too, SDIF. Don't know if anyone uses it. SDIF is used. In some communities, it is used quite heavily. In most other communities that have to exchange documents, DTDs, and public types, it is considered far too general, complex, and overhead-laden for the applications usually encountered, and simple, problem-specific arrangements are used instead. There may be some analogies here, but I will leave them to others. john From owner-ietf-822@dimacs.rutgers.edu Thu Oct 28 20:37:09 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20965; Thu, 28 Oct 93 20:31:41 EDT Received: from PO4.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20961; Thu, 28 Oct 93 20:31:39 EDT Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id UAA12782; Thu, 28 Oct 1993 20:31:36 -0400 Received: via switchmail; Thu, 28 Oct 1993 20:31:35 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 28 Oct 1993 20:30:35 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 28 Oct 1993 20:30:33 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 28 Oct 1993 20:30:31 -0400 (EDT) Message-Id: Date: Thu, 28 Oct 1993 20:30:31 -0400 (EDT) From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity In-Reply-To: References: <7C9CCE2C01842879@beyond.UUCP> Beak: Is The problem with the example is that there is no matching or -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 00:37:11 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25424; Fri, 29 Oct 93 00:27:29 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25420; Fri, 29 Oct 93 00:27:26 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Thu, 28 Oct 1993 21:27:15 PST Date: Thu, 28 Oct 1993 20:54:13 -0800 (PST) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Thu, 28 Oct 1993 12:05:39 -0700" <9310281905.AA08869@Mordor.Stanford.EDU> To: Dave Crocker Cc: Ned Freed , ietf-822@dimacs.rutgers.edu Message-Id: <01H4NSEU45SM8WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > ... > > Let's see. For each header-set header, you have to register a type, right? > > Where's the huge overhead involved in registering a subtype of multipart at > > the same time? I see no overhead here at all! > > I'm sorry, but this is nothing short of a complete red herring. > I don't understand such trivialization of concern for administrative > overhead. We are already experiencing problems and questions about > Mime content-type administration; I would think that an effort to > greatly reduce one portion of consumption would meet with some warmth, > rather than such heat. I've tried very hard to figure out what prompted you to say this, but I must confess that the reasoning here still appears completely specious to me. First of all, I am aware of no "administrative overhead" problem that needs to be solved. (I note in passing that once again the supposed benefits of the header-set proposal have shifted. There's isn't a single, solitary word about registration overhead in the current draft.) We have a real need to get the right things registered in a timely fashion. The delay here is in deciding what the right things are, how they are parameterized, and how they are canonicalized. Once these issues are settled registration has always been, and continues to be, a snap. The registration process is simple -- it getting things into a state where the registration process can be used that's hard. (I might also add that this whole header-set debate is to blame for much of the delay in this area. No smiley appears here because I'm completely serious about this.) You seem to be saying that registering a subtype under multipart in parallel with a subtype under application adds an unreasonable amount of overhead. I cannot imagine *any* competently run registration process where this would be the case. (It certainly does not seem to apply to the IANA process, which seems to be capable of dealing with multitudinous MIME object registrations quite nicely. See RFC1340 for incontestable proof of this.) And of course there's what happens after the registration process is complete: deployment. You have heard from at least three MIME implementors that the unparameterized header-set scheme is an implementation nightmare. I see the process as follows: (1) Produce a specification by: (a) Determining that a need exists. (b) Define canonical form(s). (c) Define parameters. (d) Name things. (2) Registration. (3) Implementation. (4) Deployment. Let's see. (1) is quite difficult in many cases and can take months or years. (2) is a triviality -- send it to IANA and they put it in right subtype directories and add it to the registry document. (I cannot imagine an elapsed time of any more than 30 minutes for the entire operation.) (3) is very dependent on the specification and can range from adding a viewer and a line to a mailcap file to completely rewriting lots of code. (4) is largely outside our control. So, in attempting to optimize this 4-step process you have picked the single most efficient step, a step which is unnoticeable compared to any of the others. In attempting to (at best) halve the time spent in this unnoticeable step you appear to be willing to sacrifice both expeditious implementation and timely production of specifications. The phrase "penny-wise and dollar-foolish" comes to mind... You may see this as trivialization of concern for administrative overhead. Fine. I prefer to see it as what it really is: Calling a spade a spade. Ned From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 01:07:11 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25559; Fri, 29 Oct 93 00:54:23 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25555; Fri, 29 Oct 93 00:54:21 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4JO2PBBM88WVZ4V@INNOSOFT.COM>; Thu, 28 Oct 1993 21:53:31 PST Date: Thu, 28 Oct 1993 21:50:45 -0800 (PST) From: Ned Freed Subject: RE: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Thu, 28 Oct 1993 09:58:34 -0400" <9310281358.AA13530@Accurate.COM> To: Ed Levinson Cc: Ned Freed , Keith Moore , conklin@ivory.educom.edu, ietf-822@dimacs.rutgers.edu Message-Id: <01H4NTBFOH868WVZ4V@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > SGML is a good example of "groups of files". In the I-D on sgml the > proposal is to use Multipart/SGML, have the first part be the main > document, use a Content-reference: header to match body parts to > internally referenced file names. It is not clear to me that > headerset or references is a simplification. I tend not to draw on SGML for examples because I know relatively little about it. I had things like TeX in mind here. Defining a TeX packaging would be an interesting exercise to undertake. The big problem with TeX, however, is that you have to be very careful to plug all the security holes. For example, TeX is capable of writing arbitrary files, which can be very bad news indeed. This may be an issue in SGML as well, for all I know. Ned From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 09:16:35 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27577; Fri, 29 Oct 93 08:36:29 EDT Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27573; Fri, 29 Oct 93 08:36:28 EDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA00164; Fri, 29 Oct 93 05:36:22 -0700 Message-Id: <9310291236.AA00164@Mordor.Stanford.EDU> To: Ned Freed Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Re[2]: 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 Thu, 28 Oct 93 20:54:13 -0800. <01H4NSEU45SM8WVZ4V@INNOSOFT.COM> Date: Fri, 29 Oct 93 05:36:22 -0700 From: Dave Crocker X-Mts: smtp Ned, ---- Included message: There's isn't a single, solitary word abo ut registration overhead in the current draft.) >From the current draft: "Rationale: ... Also, reduces the number of registered MIME Content-types, since those which conform to this model need to register only an Application sub-type and are not also required to register a MULTIPART subtype." Given that this didn't translate into "administrative overhead" when you read it in the doc, I probably should beef up the words. It was certainly what I had intended. Along with "user hassles" in tracking the list. I have no idea what the long-term reduction would be in absolute numbers, but for a variety of multipart-based definitions, it would reduce the number by half. On the matter of deciding whether this is really an issue, my previous reference was to such concerns as registering each variant of a given word processor format or to just register a single generic name for the "class" of formats. I have taken this as a touchstone to the topic and to suggest -- as has been said in various people's email over time -- that we should try to limit the number of subtypes defined. My own, additional, feeling is that the specs I've seen are more complicated when they have multiple content subtypes to define, so that eliminating one sub-definition would clean them up some. All of this is quite clearly in the fuzzy realms of "hassle" and preferences; no doubt about it. You have heard from at least three MIME implementors that the unparameterized header-set scheme is an implementation nightmare. Ned, I'm afraid that I heard "preference" from the 3 you refer to; yours is the only one I've seen that would seem to be summarized with the vocabulary you've offerred, above. I've also seen notes from other folks, including at least two implementors, saying they like the scheme. As to the question of whether a parameter should be present, I didn't know that was a point of contention. My sense is that things started leaning towards inclusion of a parameter a couple of days ago. Dave From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 09:46:34 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28665; Fri, 29 Oct 93 09:35:19 EDT Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28661; Fri, 29 Oct 93 09:35:18 EDT Received: from [192.52.179.3] (conklin-mac.educom.edu) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA24706; Fri, 29 Oct 1993 09:35:06 -0400 Message-Id: <199310291335.AA24706@ivory.educom.edu> Date: Fri, 29 Oct 1993 09:35:24 -0500 To: ietf-822@dimacs.rutgers.edu From: conklin@ivory.educom.edu (Jim Conklin) X-Sender: conklin@educom.edu Subject: RE: Re[2]: yet another way to indicate related MIME body parts I'm not a developer (as most of you know well!) but I wish to echo Ned's concern, which has also been troubling me as I've followed this discussion, about the delays that this issue necessarily causes in the deployment of MIME, which I personally am not convinced are warranted by the advantages proposed. I believe that MIME is needed NOW, amd I would hate to see us spend so much time refining it that it doesn't get implemented. It would really be tremendously useful to have its present capabilities widely available today. Jim From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 10:47:57 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29670; Fri, 29 Oct 93 10:26:06 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29666; Fri, 29 Oct 93 10:26:03 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA27513 (5.67a/IDA-1.5 for ); Fri, 29 Oct 1993 09:24:31 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA02505 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Fri, 29 Oct 1993 09:25:01 -0500 Message-Id: <199310291425.AA02505@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Oct 1993 09:24:24 -0500 To: ietf-822@dimacs.rutgers.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: RE: Re[2]: yet another way to indicate related MIME body parts At 9:35 AM 10/29/93 -0500, Jim Conklin wrote: > I believe that MIME is needed NOW, amd I would hate to see us spend so >much time refining it that it doesn't get implemented. It would really be >tremendously useful to have its present capabilities widely available >today. I don't think header-set is an appropriate whipping boy for the slowness of the MIME standards & implementation process, though it may be the current bottleneck in a few cases. I know the MacMIME proposal has been languishing since long before the header-set discussion began. Ned at one point indicated that he thought it would be a year before he would be interested in supporting MacMIME, and that was when the proposal was multipart/appledouble, before header-set was suggested. -- 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 Fri Oct 29 12:49:13 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00807; Fri, 29 Oct 93 12:19:08 EDT Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00803; Fri, 29 Oct 93 12:19:05 EDT Received: from rita-blanca.is.rice.edu by is.rice.edu (AA09166); Fri, 29 Oct 93 11:19:03 CDT Received: by rita-blanca.is.rice.edu (AA02432); Fri, 29 Oct 93 11:19:01 CDT Date: Fri, 29 Oct 1993 11:16:40 -0500 (CDT) From: Rick Troth Subject: Re: Text/enriched ambiguity To: John Gardiner Myers Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The problem with the > > > > example is that there is no matching or > Whoah... hang on. WHY is this a problem? I've always seen these as "commands" and coded accordingly. If you get a and then a , fine. If you get a and never encounter the , still fine. I don't see a problem with , and in fact would much PREFER it to the alternative. Here, the closing angle bracket clearly terminates the "command". > -- > _.John G. Myers Internet: jgm+@CMU.EDU -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 13:18:48 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01513; Fri, 29 Oct 93 12:45:20 EDT Received: from dxmint.cern.ch by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01509; Fri, 29 Oct 93 12:45:18 EDT Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19608; Fri, 29 Oct 1993 17:45:13 +0100 Received: by www3.cern.ch (NX5.67c/NX3.0S) id AA02376; Fri, 29 Oct 93 17:39:51 +0100 Date: Fri, 29 Oct 93 17:39:51 +0100 From: Tim Berners-Lee Message-Id: <9310291639.AA02376@www3.cern.ch> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: John C Klensin Subject: Re: yet another way to indicate related MIME body parts Cc: elevinso@accurate.com, NED@sigurd.innosoft.com, moore@cs.utk.edu, conklin@ivory.educom.edu, ietf-822@dimacs.rutgers.edu Reply-To: timbl@nxoc01.cern.ch > SDIF is used. In some communities, it is used quite heavily. > In most other communities that have to exchange documents, > DTDs, and public types, it is considered far too general, complex, ^^^^^^^^^^^^^^^^ Complexity reduces generality. The more options, them more specific the model, the smaller the sphere to which it can be applied. > and overhead-laden for > the applications usually encountered, and simple, problem-specific > arrangements are used instead. Whatever happened to simple, generic arrangements? :-) Tim From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 13:48:50 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01344; Fri, 29 Oct 93 12:33:26 EDT Received: from dxmint.cern.ch by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01336; Fri, 29 Oct 93 12:33:20 EDT Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA16295; Fri, 29 Oct 1993 17:33:16 +0100 Received: by www3.cern.ch (NX5.67c/NX3.0S) id AA02356; Fri, 29 Oct 93 17:27:55 +0100 Date: Fri, 29 Oct 93 17:27:55 +0100 From: Tim Berners-Lee Message-Id: <9310291627.AA02356@www3.cern.ch> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Dave Crocker Subject: Re: Query on a nit: Application vs. Text conten-type Cc: ietf-822@dimacs.rutgers.edu Reply-To: timbl@nxoc01.cern.ch I had always assumed that HTML would be text/html. We have jumped the gun and used that in WWW code for a year or so. To put it as Application/ seems daft. I may be way out of line on this, but personally I don't like the Application/.... bag at all. Firstly, it doesn't mean "application", it means "other". And one should be wary of any system which files most things under "other". All data has to be processed by some application. It is was designed to be a derogatory "application-specific", meaning "only one application", or "non-standard", or "proprietory", or "non-rfc", then fair enough but nothing common and well defined should go into it. It is far more useful to talk about the data representation than the application, of course. I like the initial image/ or video/ or sound/ as that really does tell me the data type, and I can chose an icon for it even if I don't understand the rest. We're not talking about whether it would frighten someone if put on a screen, but rather what *class* of object it is. I expect to be able to interconvert between different conetnt-types in the same class. Like I can convert postscript to gif. So I would want image/postscript. I guess that has been said so many times before. Not because it looks like an image, but because the abstract object which it renders is an image. If MIME puts HTML under "application" but "enriched" under "text", then the initial part of the type has become meaningless. Tim Berners-Lee Begin forwarded message: 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 Fri Oct 29 18:11:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07776; Fri, 29 Oct 93 16:10:58 EDT Received: from PO4.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07772; Fri, 29 Oct 93 16:10:57 EDT Received: from localhost (postman@localhost) by po4.andrew.cmu.edu (8.5/8.5) id QAA08471; Fri, 29 Oct 1993 16:10:50 -0400 Received: via switchmail; Fri, 29 Oct 1993 16:10:46 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 16:10:36 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 16:10:34 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 29 Oct 1993 16:10:32 -0400 (EDT) Message-Id: <0goLWsa00WBwEx1McB@andrew.cmu.edu> Date: Fri, 29 Oct 1993 16:10:32 -0400 (EDT) From: John Gardiner Myers Subject: Re: Text/enriched ambiguity To: ietf-822@dimacs.rutgers.edu In-Reply-To: References: Beak: Is One of the "simplifications" of text/enriched over text/richtext was that there are no without matching -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 18:21:06 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05958; Fri, 29 Oct 93 14:06:52 EDT Received: from RELAY.TIS.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05954; Fri, 29 Oct 93 14:06:50 EDT Received: by relay.tis.com; id AA27176; Fri, 29 Oct 93 14:04:17 EDT Received: from tis.com(192.33.112.100) by relay via smap (V1.0mjr) id sma027136; Fri Oct 29 14:03:42 1993 Received: by TIS.COM (4.1/SUN-5.64) id AA12915; Fri, 29 Oct 93 14:06:11 EDT Date: Fri, 29 Oct 93 14:06:11 EDT Message-Id: <9310291806.AA12915@TIS.COM> Reply-To: James M Galvin From: James M Galvin To: The IETF MIME working group List Subject: TIS/PEM Version 6.1 now available Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----- =_aaaaaaaaaa0" ------- =_aaaaaaaaaa0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa1" ------- =_aaaaaaaaaa1 Content-Type: text/plain; charset="us-ascii" If you have a MIME aware user agent and you install TIS/PEM, configure your user agent to pass "application/pem-1421" content types to "catrcc". This will cause the second half of this message to be verified and displayed for you. Otherwise, ignore the second half of this message. If you need certificates please contact me directly. This message was created using MH 6.8 and TIS/PEM. ------- =_aaaaaaaaaa1 Content-Type: text/plain; charset="us-ascii" A new version of TIS/PEM, Trusted Information Systems' Privacy Enhanced Mail package, is now available for FTP within the United States and Canada. TIS/PEM was developed under ARPA sponsorship and in cooperation with RSA Data Security Incorporated (RSADSI) for non-commercial use (not for sale or inclusion in a product) within the US and Canada. TIS/PEM version 6.1 is a major maintenance release. It generates correctly formed Certificate Revocation Lists, is easier to install, performs better, and contains fixes for all previously reported bugs. If you are running an older version of TIS/PEM, we strongly recommend that you upgrade to 6.1 to guarantee interoperability. If you have a UNIX system and would like to add digital signatures and confidentiality to your mail, give TIS/PEM a try. Enclosed below is the TIS/PEM FAQ. ------- =_aaaaaaaaaa1 Content-Type: text/plain; charset="us-ascii" Content-Description: TIS/PEM FAQ TIS/PEM FAQ Last updated 29 October 1993 Send questions and comments to tispem-support@tis.com Questions answered: 1) What is Privacy Enhanced Mail (PEM)? * 2) Where are the PEM standards defined? 3) Is there a forum for PEM developers and others interested in the PEM standards? * 4) Are there implementations of PEM available? * 5) How do I get TIS/PEM? 6) Why is TIS/PEM only available in the US and Canada? 7) Are special privileges (e.g., root access) required to install TIS/PEM? 8) What about integrating TIS/PEM into mail user agents? 9) What about DOS and other non-UNIX platforms? 10) What about certificates? 11) What is a distinguished name? 12) What is a Certification Authority (CA)? 13) What does a PCA do and how are they differentiated? 14) What PCAs are available? 15) How much does it cost to sign up under a PCA? 16) What if I have questions about TIS PCA? 17) Is there a mailing list for TIS/PEM users? 18) What if I have questions about or problems with TIS/PEM? + 19) Can PEM be used with MIME? * means that this entry has been recently updated. + means that this entry has been added recently. 1 Q: What is Privacy Enhanced Mail (PEM)? A: PEM is an Internet standard for providing security services to electronic mail. It uses cryptographic techniques to provide message integrity checking, originator authentication, and confidentiality. It lets you know that a message hasn't been changed, who it's from, and, optionally, allows you to keep it secret from all but the intended recipients. 2 Q: Where are the PEM standards defined? A: There is a set of Proposed Standard RFCs (Internet standards documents) that specify PEM. The four new documents are RFCs 1421 (obsoletes 1113), 1422 (obsoletes 1114), 1423 (obsoletes 1115), and 1424 (new). These documents may be found in your favorite RFC repository. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs An overview of PEM was presented in the August 1993 issue (Volume 36, Number 8) of "Communications of the ACM" in an article entitled "Internet Privacy Enhanced Mail" by Stephen T. Kent. 3 Q: Is there a forum for PEM developers and others interested in the PEM standards? A: Yes, there is an electronic mailing list that is used to discuss the PEM specifications, implementation issues, and it is used to conduct some of the business of the Internet Engineering Task Force (IETF) PEM working group. Send a message to "pem-dev-request@tis.com" if you would like to be added to the list. 4 Q: Are there implementations of PEM available? A: Yes, implementations are being made available as you read this. Trusted Information Systems (TIS), under ARPA sponsorship and in cooperation with RSA Data Security Incorporated (RSADSI), has released a reference implementation of Privacy Enhanced Mail (TIS/PEM) to the Internet community. TIS/PEM is a UNIX-based implementation that has been integrated with Rand MH 6.7.2 and is easily integrated into other mail user agents. TIS/PEM is distributed in source form. It is openly available within the United States and Canada for non-commercial use (not for resale). The current version of TIS/PEM is 6.1. If you are running an earlier version, we suggest that you install 6.1. 6.1 contains many bug fixes and functionality not available in previous versions. Vendors interested in including TIS/PEM functionality in their products can contact Trusted Information Systems about licensing Trusted Mail (tm). 5 Q: How do I get TIS/PEM? A: TIS/PEM is available via anonymous ftp in the United States and Canada to US and Canadian citizens and people with a US "green card." To retrieve TIS/PEM please FTP to host: ftp.tis.com login: anonymous and retrieve the files pub/PEM/README pub/PEM/LICENSE pub/PEM/BUGS The README file contains further instructions. The current version of TIS/PEM is 6.1. If you are running an earlier version, we suggest that you install 6.1. 6.1 contains many bug fixes and functionality not available in previous versions. 6 Q: Why is TIS/PEM only available in the US and Canada? A: The export from the United States of the cryptography used in TIS/PEM is controlled by the United States government. 7 Q: Are special privileges (e.g., root access) required to install TIS/PEM? A: TIS/PEM can be installed in multi-user mode, which is identified by the use of a single, system-wide, shared database of cryptographic and administrative information maintained by one or more privileged users called certificate administrators, and single-user mode, which allows individuals to maintain their own databases of cryptographic and administrative information. Multi-user mode installation requires privileges, while single-user mode installation does not. 8 Q: What about integrating TIS/PEM into mail user agents? A: TIS/PEM has been integrated with MH 6.7.2 and is easily integrated with other mail user agents. If you integrate TIS/PEM with a popular mail user agent, we would be happy to make it available to others. Additionally, a set of filters, similar to the UNIX cat command, that allow you to apply and remove PEM enhancements (enhance and de-enhance) text files are provided. These filters make it possible to use PEM with mail user agents that are not PEM aware. 9 Q: What about DOS and other non-UNIX platforms? A: TIS/PEM is currently limited to UNIX, but we are pursuing porting it to other operating systems. 10 Q: What about certificates? A: While PEM uses X.509 certificates to bind distinguished names to RSA public keys, it is not necessary to join the Internet certification hierarchy or otherwise pay to use TIS/PEM. TIS/PEM is capable of generating the certificates that you need. Joining the Internet certification hierarchy has the benefit of making it easier to verify others' mail and for them to verify yours. To join the Internet certification hierarchy, you must sign up your Certification Authority (CA) under a Policy-level Certification Authority (PCA). 11 Q: What is a distinguished name? A: A distinguished name is a hierarchical, globally unique name used to identify something or someone. RFC 1255 and several North American Directory Forum (NADF) documents describe how to select appropriate distinguished names. The distinguished name for Earl Sinclair (a fictional character, geographically displaced) might be Country=US State or Province=CA Organization=Wesayso Corporation Organizational Unit=Tree Pushing Division Common Name=Earl Sinclair 12 Q: What is a Certification Authority (CA)? A: A Certification Authority (CA) vouches for the binding between users' distinguished names and RSA public keys within an organization or organizational unit. The CA's distinguished name is that of the organization or organizational unit and users' distinguished names are created by starting with the CA distinguished name and adding something to uniquely and unambiguously identify the user, like a common name. 13 Q: What does a PCA do and how are they differentiated? A: PCAs vouch for the binding between a CA's distinguished name and RSA public key. By joining a PCA, others can verify your PEM messages by following the certification path to the Internet Policy-level Certification Authority certificate without having to have retrieved your RSA public key using secure, out of band means. PCAs may also make CA Certificate Revocation Lists (CRLs) and certificates available and provide other services for its members. PCAs can be differentiated by the policy that they advertise. The policy includes the level of effort -- and associated assurance -- that a PCA uses to insure the correctness of the binding and the requirements they place on CAs which issue certificates under them. They can also be differentiated by the other services they offer and their price. 14 Q: What PCAs are available? A: Several PCAs exist as part of the Internet certification hierarchy, including PCAs at RSADSI and TIS, and more may come online in the near future. 15 Q: How much does it cost to sign up under a PCA? A: Individual PCAs will have their own price schedules. Signing up under the TIS PCA is free during 1993. 16 Q: What if I have questions about TIS PCA? A: Sent them to tispca-info@tis.com. 17 Q: Is there a mailing list for TIS/PEM users? A: Yes, it's tispem-users@tis.com. Send mail to tispem-users-request@tis.com to be added to or deleted from the list. 18 Q: What if I have questions about or problems with TIS/PEM? A: Send them to tispem-support@tis.com. 19 Q: Can PEM be used with MIME? A: Yes. The body of PEM message, as defined by RFC 1421, could be placed inside a MIME body part labelled "application/pem-1421". In addition, the PEM working group of the IETF is working on a specification for an integration that will allow PEM to take advantage of the structure framework provided by MIME. You may ask for more information on the PEM developers mailing list, "pem-dev@tis.com". ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0 Content-Type: application/pem-1421 Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQUklWQUNZLUVOSEFOQ0VEIE1FU1NBR0UtLS0tLQpQcm9jLVR5cGU6IDQsTUlD LUNMRUFSCkNvbnRlbnQtRG9tYWluOiBSRkM4MjIKT3JpZ2luYXRvci1DZXJ0aWZpY2F0ZTogTUlJ Q0JqQ0NBVzhDQVFJd0RRWUpLb1pJaHZjTkFRRUNCUUF3VXpFTE0KIEFrR0ExVUVCaE1DVlZNeEN6 QUpCZ05WQkFnVEFrMUVNU1F3SWdZRFZRUUtFeHRVY25WemRHVmtJRWx1Wm05eWIKIFdGMGFXOXVJ Rk41YzNSbGJYTXhFVEFQQmdOVkJBc1RDRWRzWlc1M2IyOWtNQjRYRFRrek1EVXlPVEEwTVRZeE8K IFZvWERUazFNRFV5T1RBME1UWXhPVm93YlRFTE1Ba0dBMVVFQmhNQ1ZWTXhDekFKQmdOVkJBZ1RB azFFTVNRd0kKIGdZRFZRUUtFeHRVY25WemRHVmtJRWx1Wm05eWJXRjBhVzl1SUZONWMzUmxiWE14 RVRBUEJnTlZCQXNUQ0Vkc1oKIFc1M2IyOWtNUmd3RmdZRFZRUURFdzlLWVcxbGN5Qk5MaUJIWVd4 MmFXNHdkekFLQmdSVkNBRUJBZ0lEQUFOcEEKIERCbUFtRUEzZmFCYzNQNzhTQkM0M2ZvK2F2Vy9O VnJQOWliYmUvSGl0N29XMndpaTF3Wi9RaUpIR2k5bEF2ZnIKIERGdGJKVW1tcVIydHhuYjMwbGIy VHpzY1pWL2ducmVaS3R3TG94My9SekJSUWVOTlp2MlJ0Qzl5TUp5R3RzWEoKIE5NR2dkcmZBZ0VE TUEwR0NTcUdTSWIzRFFFQkFnVUFBNEdCQURGRzI4LzI3Q1R3OGRLUjExK1kyLy9NbFZWcEgKIG9m K3k5a3hMSzlTZWJpOTFIZktTdE5TQnE0bm4zbHViYkdRVmcwZDJrVzlVZ0RtdlVTMDZsbmUySVdX WU1Yd2QKIFhWclRaejd3K01BY2xCanJXaHcxaWt2OTNHVXo0RXpzMldFNWJ6YkZvbWdiVlVER3FD Wmt4MmNxWWZ1QkdZSlEKIDMxS093MXMzVWhEYitPSwpJc3N1ZXItQ2VydGlmaWNhdGU6IE1JSUNB VENDQVdvQ0FRSXdEUVlKS29aSWh2Y05BUUVDQlFBd1JERUxNQWtHQQogMVVFQmhNQ1ZWTXhDekFK QmdOVkJBZ1RBazFFTVNnd0pnWURWUVFLRXg5VWNuVnpkR1ZrSUVsdVptOXliV0YwYQogVzl1SUZO NWMzUmxiWE1nVUVOQk1CNFhEVGt6TURVeU9UQXdNRGMwTWxvWERUazFNRFV5T1RBd01EYzBNbG93 VQogekVMTUFrR0ExVUVCaE1DVlZNeEN6QUpCZ05WQkFnVEFrMUVNU1F3SWdZRFZRUUtFeHRVY25W emRHVmtJRWx1WgogbTl5YldGMGFXOXVJRk41YzNSbGJYTXhFVEFQQmdOVkJBc1RDRWRzWlc1M2Iy OWtNSUdhTUFvR0JGVUlBUUVDQQogZ1FBQTRHTEFEQ0Jod0tCZ1FDM2FwRXFKTUZWYm5oeTNvcDRk Nk5xYlFveDIzbnBrSnRQSW5iZjROUWk0L1ptRQogOG1veW0zWmxhdFNrcGtLUWVhUTFJUERlSlNZ UVVzcDJTUnhXSEUyR2ZiQmNKbjlvYkRTMUI3aS9GOFJFMU9iVAogR24vZXVOY2VkOTZzUlJOdnJl NWFQcXQ2TkdXa3dUSEhraUs4L1d3ei9FVnFCZ1Z0YU5sRDR2QVdhNmhYd0lCQQogekFOQmdrcWhr aUc5dzBCQVFJRkFBT0JnUUJvdi9JZS9qaW8weVpGcGxaR2hXZU50bGdDYXdnM2FzWngzLy9ZYgog U1BVb2JGMDhHT1pzRkQ2RHZTSVJGVEFpM1Q2NmlSTUhiUkU2Q1BZSXVPYkNEMndRQXZyVTVzaU5t M2ZDTTcweAogL3FaZjZuMkw5azkxSXZzZkxLeDg0ZnIwanRvS1M5SVpqMjhHTGxJZnc5NEFnMWJt Y1JoUlBoQnNSeGhKNHdHWgogR01xOWc9PQpJc3N1ZXItQ2VydGlmaWNhdGU6IE1JSUI4akNDQVZz Q0FRRXdEUVlKS29aSWh2Y05BUUVDQlFBd1JERUxNQWtHQQogMVVFQmhNQ1ZWTXhDekFKQmdOVkJB Z1RBazFFTVNnd0pnWURWUVFLRXg5VWNuVnpkR1ZrSUVsdVptOXliV0YwYQogVzl1SUZONWMzUmxi WE1nVUVOQk1CNFhEVGt6TURVeU9ERTNNVEV5TjFvWERUazFNRFV5T0RFM01URXlOMW93UgogREVM TUFrR0ExVUVCaE1DVlZNeEN6QUpCZ05WQkFnVEFrMUVNU2d3SmdZRFZRUUtFeDlVY25WemRHVmtJ RWx1WgogbTl5YldGMGFXOXVJRk41YzNSbGJYTWdVRU5CTUlHYU1Bb0dCRlVJQVFFQ0FnUUFBNEdM QURDQmh3S0JnUURiTAogeGFSbFMzdTU0eXlSZ1ZESTVkY0U5bmxhc0w4ZkpxT0dseW83eEgyRlpu cjNrVWZzRmo3T0dpWXNyNlVidnF3SwogbnlmTUlSVXJYRFVhNjRsZUdtZnQzU0syN3BzRFVIT3lu UlNDYzQwZC9IckRmODEwVTV0blRhbUJLVUlNcWl2SwogNEdvTDB0TVJBMWVYNmhBTEF2TExnSzFI Ym53WkFvNkdxUUdXOENJSlFJQkF6QU5CZ2txaGtpRzl3MEJBUUlGQQogQU9CZ1FEQnA1YUM2b1Y2 SXVGaThKQ2N0cTU3YmV3NjA0SEhObGxnampwN3pkWGFmcTZqY3RSZzJnOTFrL3lGVwogaDE5YkpD L3ROcmIwV1Z3dVpPczVML0ZUb1BNTklJSHphVy9ZU1JPQm15aFREWWFLSFpHajBQMStpTmpNYkh0 OQogZG0xUUVIR0lmS2dCd0ZpZEl0bk9hNzREZmtYZGlqbFBSbnIvK0UySWI2UE0raEVmUT09Ck1J Qy1JbmZvOiBSU0EtTUQ1LFJTQSxRRWhRS2pWckZhaFNhU0FJVHpHT1FFck5kZThWeVhWMUttSlF2 TE9pUTRDCiBzbjdnOCtBNUFzVThpYzFHK1lpcmNReXg3aUNSZE9TQjAwUDZnK2trNG51Q0lXTkll YS8xNStsVzFRN0paMDhFCiA0S01EalFxK1hSU3lHOUZOcXJaM0IKCkEgbmV3IHZlcnNpb24gb2Yg VElTL1BFTSwgVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zJyBQcml2YWN5DQpFbmhhbmNlZCBN YWlsIHBhY2thZ2UsIGlzIG5vdyBhdmFpbGFibGUgZm9yIEZUUCB3aXRoaW4gdGhlIFVuaXRlZA0K U3RhdGVzIGFuZCBDYW5hZGEuICBUSVMvUEVNIHdhcyBkZXZlbG9wZWQgdW5kZXIgQVJQQSBzcG9u c29yc2hpcCBhbmQNCmluIGNvb3BlcmF0aW9uIHdpdGggUlNBIERhdGEgU2VjdXJpdHkgSW5jb3Jw b3JhdGVkIChSU0FEU0kpIGZvcg0Kbm9uLWNvbW1lcmNpYWwgdXNlIChub3QgZm9yIHNhbGUgb3Ig aW5jbHVzaW9uIGluIGEgcHJvZHVjdCkgd2l0aGluIHRoZQ0KVVMgYW5kIENhbmFkYS4NCg0KVElT L1BFTSB2ZXJzaW9uIDYuMSBpcyBhIG1ham9yIG1haW50ZW5hbmNlIHJlbGVhc2UuICBJdCBnZW5l cmF0ZXMNCmNvcnJlY3RseSBmb3JtZWQgQ2VydGlmaWNhdGUgUmV2b2NhdGlvbiBMaXN0cywgaXMg ZWFzaWVyIHRvIGluc3RhbGwsDQpwZXJmb3JtcyBiZXR0ZXIsIGFuZCBjb250YWlucyBmaXhlcyBm b3IgYWxsIHByZXZpb3VzbHkgcmVwb3J0ZWQgYnVncy4NCg0KSWYgeW91IGFyZSBydW5uaW5nIGFu IG9sZGVyIHZlcnNpb24gb2YgVElTL1BFTSwgd2Ugc3Ryb25nbHkgcmVjb21tZW5kDQp0aGF0IHlv dSB1cGdyYWRlIHRvIDYuMSB0byBndWFyYW50ZWUgaW50ZXJvcGVyYWJpbGl0eS4gIElmIHlvdSBo YXZlIGENClVOSVggc3lzdGVtIGFuZCB3b3VsZCBsaWtlIHRvIGFkZCBkaWdpdGFsIHNpZ25hdHVy ZXMgYW5kDQpjb25maWRlbnRpYWxpdHkgdG8geW91ciBtYWlsLCBnaXZlIFRJUy9QRU0gYSB0cnku DQoNCkVuY2xvc2VkIGJlbG93IGlzIHRoZSBUSVMvUEVNIEZBUS4NCgwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFRJUy9QRU0gRkFRDQogICAgICAgICAgICAgICAgICAgICAgICAg IExhc3QgdXBkYXRlZCAyOSBPY3RvYmVyIDE5OTMNCiAgICAgICAgICAgICBTZW5kIHF1ZXN0aW9u cyBhbmQgY29tbWVudHMgdG8gdGlzcGVtLXN1cHBvcnRAdGlzLmNvbQ0KDQpRdWVzdGlvbnMgYW5z d2VyZWQ6DQoNCiAgIDEpIFdoYXQgaXMgUHJpdmFjeSBFbmhhbmNlZCBNYWlsIChQRU0pPw0KKiAg MikgV2hlcmUgYXJlIHRoZSBQRU0gc3RhbmRhcmRzIGRlZmluZWQ/DQogICAzKSBJcyB0aGVyZSBh IGZvcnVtIGZvciBQRU0gZGV2ZWxvcGVycyBhbmQgb3RoZXJzIGludGVyZXN0ZWQgaW4gdGhlDQog ICAgICBQRU0gc3RhbmRhcmRzPw0KKiAgNCkgQXJlIHRoZXJlIGltcGxlbWVudGF0aW9ucyBvZiBQ RU0gYXZhaWxhYmxlPw0KKiAgNSkgSG93IGRvIEkgZ2V0IFRJUy9QRU0/DQogICA2KSBXaHkgaXMg VElTL1BFTSBvbmx5IGF2YWlsYWJsZSBpbiB0aGUgVVMgYW5kIENhbmFkYT8NCiAgIDcpIEFyZSBz cGVjaWFsIHByaXZpbGVnZXMgKGUuZy4sIHJvb3QgYWNjZXNzKSByZXF1aXJlZCB0byBpbnN0YWxs DQogICAgICBUSVMvUEVNPw0KICAgOCkgV2hhdCBhYm91dCBpbnRlZ3JhdGluZyBUSVMvUEVNIGlu dG8gbWFpbCB1c2VyIGFnZW50cz8NCiAgIDkpIFdoYXQgYWJvdXQgRE9TIGFuZCBvdGhlciBub24t VU5JWCBwbGF0Zm9ybXM/DQogIDEwKSBXaGF0IGFib3V0IGNlcnRpZmljYXRlcz8NCiAgMTEpIFdo YXQgaXMgYSBkaXN0aW5ndWlzaGVkIG5hbWU/DQogIDEyKSBXaGF0IGlzIGEgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgKENBKT8NCiAgMTMpIFdoYXQgZG9lcyBhIFBDQSBkbyBhbmQgaG93IGFyZSB0 aGV5IGRpZmZlcmVudGlhdGVkPw0KICAxNCkgV2hhdCBQQ0FzIGFyZSBhdmFpbGFibGU/DQogIDE1 KSBIb3cgbXVjaCBkb2VzIGl0IGNvc3QgdG8gc2lnbiB1cCB1bmRlciBhIFBDQT8NCiAgMTYpIFdo YXQgaWYgSSBoYXZlIHF1ZXN0aW9ucyBhYm91dCBUSVMgUENBPw0KICAxNykgSXMgdGhlcmUgYSBt YWlsaW5nIGxpc3QgZm9yIFRJUy9QRU0gdXNlcnM/DQogIDE4KSBXaGF0IGlmIEkgaGF2ZSBxdWVz dGlvbnMgYWJvdXQgb3IgcHJvYmxlbXMgd2l0aCBUSVMvUEVNPw0KKyAxOSkgQ2FuIFBFTSBiZSB1 c2VkIHdpdGggTUlNRT8NCg0KICogbWVhbnMgdGhhdCB0aGlzIGVudHJ5IGhhcyBiZWVuIHJlY2Vu dGx5IHVwZGF0ZWQuDQogKyBtZWFucyB0aGF0IHRoaXMgZW50cnkgaGFzIGJlZW4gYWRkZWQgcmVj ZW50bHkuDQoNCjENClE6IFdoYXQgaXMgUHJpdmFjeSBFbmhhbmNlZCBNYWlsIChQRU0pPw0KDQpB OiBQRU0gaXMgYW4gSW50ZXJuZXQgc3RhbmRhcmQgZm9yIHByb3ZpZGluZyBzZWN1cml0eSBzZXJ2 aWNlcyB0bw0KICAgZWxlY3Ryb25pYyBtYWlsLiAgSXQgdXNlcyBjcnlwdG9ncmFwaGljIHRlY2hu aXF1ZXMgdG8gcHJvdmlkZQ0KICAgbWVzc2FnZSBpbnRlZ3JpdHkgY2hlY2tpbmcsIG9yaWdpbmF0 b3IgYXV0aGVudGljYXRpb24sIGFuZA0KICAgY29uZmlkZW50aWFsaXR5LiAgSXQgbGV0cyB5b3Ug a25vdyB0aGF0IGEgbWVzc2FnZSBoYXNuJ3QgYmVlbg0KICAgY2hhbmdlZCwgd2hvIGl0J3MgZnJv bSwgYW5kLCBvcHRpb25hbGx5LCBhbGxvd3MgeW91IHRvIGtlZXAgaXQNCiAgIHNlY3JldCBmcm9t IGFsbCBidXQgdGhlIGludGVuZGVkIHJlY2lwaWVudHMuDQoNCjINClE6IFdoZXJlIGFyZSB0aGUg UEVNIHN0YW5kYXJkcyBkZWZpbmVkPw0KDQpBOiBUaGVyZSBpcyBhIHNldCBvZiBQcm9wb3NlZCBT dGFuZGFyZCBSRkNzIChJbnRlcm5ldCBzdGFuZGFyZHMNCiAgIGRvY3VtZW50cykgdGhhdCBzcGVj aWZ5IFBFTS4gIFRoZSBmb3VyIG5ldyBkb2N1bWVudHMgYXJlIFJGQ3MgMTQyMQ0KICAgKG9ic29s ZXRlcyAxMTEzKSwgMTQyMiAob2Jzb2xldGVzIDExMTQpLCAxNDIzIChvYnNvbGV0ZXMgMTExNSks IGFuZA0KICAgMTQyNCAobmV3KS4gIFRoZXNlIGRvY3VtZW50cyBtYXkgYmUgZm91bmQgaW4geW91 ciBmYXZvcml0ZSBSRkMNCiAgIHJlcG9zaXRvcnkuICBEZXRhaWxzIG9uIG9idGFpbmluZyBSRkNz IHZpYSBGVFAgb3IgRU1BSUwgbWF5IGJlDQogICBvYnRhaW5lZCBieSBzZW5kaW5nIGFuIEVNQUlM IG1lc3NhZ2UgdG8gInJmYy1pbmZvQElTSS5FRFUiIHdpdGggdGhlDQogICBtZXNzYWdlIGJvZHkg ImhlbHA6IHdheXNfdG9fZ2V0X3JmY3MiLiAgRm9yIGV4YW1wbGU6DQoNCiAgICAgICAgVG86IHJm Yy1pbmZvQElTSS5FRFUNCiAgICAgICAgU3ViamVjdDogZ2V0dGluZyByZmNzDQoNCiAgICAgICAg aGVscDogd2F5c190b19nZXRfcmZjcw0KDQogICBBbiBvdmVydmlldyBvZiBQRU0gd2FzIHByZXNl bnRlZCBpbiB0aGUgQXVndXN0IDE5OTMgaXNzdWUgKFZvbHVtZQ0KICAgMzYsIE51bWJlciA4KSBv ZiAiQ29tbXVuaWNhdGlvbnMgb2YgdGhlIEFDTSIgaW4gYW4gYXJ0aWNsZSBlbnRpdGxlZA0KICAg IkludGVybmV0IFByaXZhY3kgRW5oYW5jZWQgTWFpbCIgYnkgU3RlcGhlbiBULiBLZW50Lg0KDQoz DQpROiBJcyB0aGVyZSBhIGZvcnVtIGZvciBQRU0gZGV2ZWxvcGVycyBhbmQgb3RoZXJzIGludGVy ZXN0ZWQgaW4gdGhlDQogICBQRU0gc3RhbmRhcmRzPw0KDQpBOiBZZXMsIHRoZXJlIGlzIGFuIGVs ZWN0cm9uaWMgbWFpbGluZyBsaXN0IHRoYXQgaXMgdXNlZCB0byBkaXNjdXNzDQogICB0aGUgUEVN IHNwZWNpZmljYXRpb25zLCBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMsIGFuZCBpdCBpcyB1c2VkIHRv DQogICBjb25kdWN0IHNvbWUgb2YgdGhlIGJ1c2luZXNzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZyBUYXNrIEZvcmNlDQogICAoSUVURikgUEVNIHdvcmtpbmcgZ3JvdXAuICBTZW5kIGEgbWVz c2FnZSB0bw0KICAgInBlbS1kZXYtcmVxdWVzdEB0aXMuY29tIiBpZiB5b3Ugd291bGQgbGlrZSB0 byBiZSBhZGRlZCB0byB0aGUNCiAgIGxpc3QuDQoNCjQNClE6IEFyZSB0aGVyZSBpbXBsZW1lbnRh dGlvbnMgb2YgUEVNIGF2YWlsYWJsZT8NCg0KQTogWWVzLCBpbXBsZW1lbnRhdGlvbnMgYXJlIGJl aW5nIG1hZGUgYXZhaWxhYmxlIGFzIHlvdSByZWFkIHRoaXMuDQogICBUcnVzdGVkIEluZm9ybWF0 aW9uIFN5c3RlbXMgKFRJUyksIHVuZGVyIEFSUEEgc3BvbnNvcnNoaXAgYW5kIGluDQogICBjb29w ZXJhdGlvbiB3aXRoIFJTQSBEYXRhIFNlY3VyaXR5IEluY29ycG9yYXRlZCAoUlNBRFNJKSwgaGFz DQogICByZWxlYXNlZCBhIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiBvZiBQcml2YWN5IEVuaGFu Y2VkIE1haWwNCiAgIChUSVMvUEVNKSB0byB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LiAgDQoNCiAg IFRJUy9QRU0gaXMgYSBVTklYLWJhc2VkIGltcGxlbWVudGF0aW9uIHRoYXQgaGFzIGJlZW4gaW50 ZWdyYXRlZA0KICAgd2l0aCBSYW5kIE1IIDYuNy4yIGFuZCBpcyBlYXNpbHkgaW50ZWdyYXRlZCBp bnRvIG90aGVyIG1haWwgdXNlcg0KICAgYWdlbnRzLiAgVElTL1BFTSBpcyBkaXN0cmlidXRlZCBp biBzb3VyY2UgZm9ybS4gIEl0IGlzIG9wZW5seQ0KICAgYXZhaWxhYmxlIHdpdGhpbiB0aGUgVW5p dGVkIFN0YXRlcyBhbmQgQ2FuYWRhIGZvciBub24tY29tbWVyY2lhbA0KICAgdXNlIChub3QgZm9y IHJlc2FsZSkuDQoNCiAgIFRoZSBjdXJyZW50IHZlcnNpb24gb2YgVElTL1BFTSBpcyA2LjEuICBJ ZiB5b3UgYXJlIHJ1bm5pbmcgYW4NCiAgIGVhcmxpZXIgdmVyc2lvbiwgd2Ugc3VnZ2VzdCB0aGF0 IHlvdSBpbnN0YWxsIDYuMS4gIDYuMSBjb250YWlucw0KICAgbWFueSBidWcgZml4ZXMgYW5kIGZ1 bmN0aW9uYWxpdHkgbm90IGF2YWlsYWJsZSBpbiBwcmV2aW91cw0KICAgdmVyc2lvbnMuDQoNCiAg IFZlbmRvcnMgaW50ZXJlc3RlZCBpbiBpbmNsdWRpbmcgVElTL1BFTSBmdW5jdGlvbmFsaXR5IGlu IHRoZWlyDQogICBwcm9kdWN0cyBjYW4gY29udGFjdCBUcnVzdGVkIEluZm9ybWF0aW9uIFN5c3Rl bXMgYWJvdXQgbGljZW5zaW5nDQogICBUcnVzdGVkIE1haWwgKHRtKS4NCg0KNQ0KUTogSG93IGRv IEkgZ2V0IFRJUy9QRU0/DQoNCkE6IFRJUy9QRU0gaXMgYXZhaWxhYmxlIHZpYSBhbm9ueW1vdXMg ZnRwIGluIHRoZSBVbml0ZWQgU3RhdGVzIGFuZA0KICAgQ2FuYWRhIHRvIFVTIGFuZCBDYW5hZGlh biBjaXRpemVucyBhbmQgcGVvcGxlIHdpdGggYSBVUyAiZ3JlZW4NCiAgIGNhcmQuIiAgVG8gcmV0 cmlldmUgVElTL1BFTSBwbGVhc2UgRlRQIHRvDQoNCiAgICAgaG9zdDogICBmdHAudGlzLmNvbQ0K ICAgICBsb2dpbjogIGFub255bW91cw0KDQogICBhbmQgcmV0cmlldmUgdGhlIGZpbGVzDQoNCiAg ICAgcHViL1BFTS9SRUFETUUNCiAgICAgcHViL1BFTS9MSUNFTlNFDQogICAgIHB1Yi9QRU0vQlVH Uw0KDQogICBUaGUgUkVBRE1FIGZpbGUgY29udGFpbnMgZnVydGhlciBpbnN0cnVjdGlvbnMuICAN Cg0KICAgVGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBUSVMvUEVNIGlzIDYuMS4gIElmIHlvdSBhcmUg cnVubmluZyBhbg0KICAgZWFybGllciB2ZXJzaW9uLCB3ZSBzdWdnZXN0IHRoYXQgeW91IGluc3Rh bGwgNi4xLiAgNi4xIGNvbnRhaW5zDQogICBtYW55IGJ1ZyBmaXhlcyBhbmQgZnVuY3Rpb25hbGl0 eSBub3QgYXZhaWxhYmxlIGluIHByZXZpb3VzDQogICB2ZXJzaW9ucy4NCg0KNg0KUTogV2h5IGlz IFRJUy9QRU0gb25seSBhdmFpbGFibGUgaW4gdGhlIFVTIGFuZCBDYW5hZGE/DQoNCkE6IFRoZSBl eHBvcnQgZnJvbSB0aGUgVW5pdGVkIFN0YXRlcyBvZiB0aGUgY3J5cHRvZ3JhcGh5IHVzZWQgaW4N CiAgIFRJUy9QRU0gaXMgY29udHJvbGxlZCBieSB0aGUgVW5pdGVkIFN0YXRlcyBnb3Zlcm5tZW50 Lg0KDQo3DQpROiBBcmUgc3BlY2lhbCBwcml2aWxlZ2VzIChlLmcuLCByb290IGFjY2VzcykgcmVx dWlyZWQgdG8gaW5zdGFsbCBUSVMvUEVNPw0KDQpBOiBUSVMvUEVNIGNhbiBiZSBpbnN0YWxsZWQg aW4gbXVsdGktdXNlciBtb2RlLCB3aGljaCBpcyBpZGVudGlmaWVkIGJ5DQogICB0aGUgdXNlIG9m IGEgc2luZ2xlLCBzeXN0ZW0td2lkZSwgc2hhcmVkIGRhdGFiYXNlIG9mIGNyeXB0b2dyYXBoaWMN CiAgIGFuZCBhZG1pbmlzdHJhdGl2ZSBpbmZvcm1hdGlvbiBtYWludGFpbmVkIGJ5IG9uZSBvciBt b3JlIHByaXZpbGVnZWQNCiAgIHVzZXJzIGNhbGxlZCBjZXJ0aWZpY2F0ZSBhZG1pbmlzdHJhdG9y cywgYW5kIHNpbmdsZS11c2VyIG1vZGUsDQogICB3aGljaCBhbGxvd3MgaW5kaXZpZHVhbHMgdG8g bWFpbnRhaW4gdGhlaXIgb3duIGRhdGFiYXNlcyBvZg0KICAgY3J5cHRvZ3JhcGhpYyBhbmQgYWRt aW5pc3RyYXRpdmUgaW5mb3JtYXRpb24uICBNdWx0aS11c2VyIG1vZGUNCiAgIGluc3RhbGxhdGlv biByZXF1aXJlcyBwcml2aWxlZ2VzLCB3aGlsZSBzaW5nbGUtdXNlciBtb2RlDQogICBpbnN0YWxs YXRpb24gZG9lcyBub3QuDQoNCjgNClE6IFdoYXQgYWJvdXQgaW50ZWdyYXRpbmcgVElTL1BFTSBp bnRvIG1haWwgdXNlciBhZ2VudHM/DQoNCkE6IFRJUy9QRU0gaGFzIGJlZW4gaW50ZWdyYXRlZCB3 aXRoIE1IIDYuNy4yIGFuZCBpcyBlYXNpbHkgaW50ZWdyYXRlZA0KICAgd2l0aCBvdGhlciBtYWls IHVzZXIgYWdlbnRzLiAgSWYgeW91IGludGVncmF0ZSBUSVMvUEVNIHdpdGggYQ0KICAgcG9wdWxh ciBtYWlsIHVzZXIgYWdlbnQsIHdlIHdvdWxkIGJlIGhhcHB5IHRvIG1ha2UgaXQgYXZhaWxhYmxl IHRvDQogICBvdGhlcnMuICANCg0KICAgQWRkaXRpb25hbGx5LCBhIHNldCBvZiBmaWx0ZXJzLCBz aW1pbGFyIHRvIHRoZSBVTklYIGNhdCBjb21tYW5kLA0KICAgdGhhdCBhbGxvdyB5b3UgdG8gYXBw bHkgYW5kIHJlbW92ZSBQRU0gZW5oYW5jZW1lbnRzIChlbmhhbmNlIGFuZA0KICAgZGUtZW5oYW5j ZSkgdGV4dCBmaWxlcyBhcmUgcHJvdmlkZWQuICBUaGVzZSBmaWx0ZXJzIG1ha2UgaXQNCiAgIHBv c3NpYmxlIHRvIHVzZSBQRU0gd2l0aCBtYWlsIHVzZXIgYWdlbnRzIHRoYXQgYXJlIG5vdCBQRU0g YXdhcmUuDQoNCjkNClE6IFdoYXQgYWJvdXQgRE9TIGFuZCBvdGhlciBub24tVU5JWCBwbGF0Zm9y bXM/DQoNCkE6IFRJUy9QRU0gaXMgY3VycmVudGx5IGxpbWl0ZWQgdG8gVU5JWCwgYnV0IHdlIGFy ZSBwdXJzdWluZyBwb3J0aW5nDQogICBpdCB0byBvdGhlciBvcGVyYXRpbmcgc3lzdGVtcy4NCg0K MTANClE6IFdoYXQgYWJvdXQgY2VydGlmaWNhdGVzPw0KDQpBOiBXaGlsZSBQRU0gdXNlcyBYLjUw OSBjZXJ0aWZpY2F0ZXMgdG8gYmluZCBkaXN0aW5ndWlzaGVkIG5hbWVzIHRvDQogICBSU0EgcHVi bGljIGtleXMsIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gam9pbiB0aGUgSW50ZXJuZXQNCiAgIGNl cnRpZmljYXRpb24gaGllcmFyY2h5IG9yIG90aGVyd2lzZSBwYXkgdG8gdXNlIFRJUy9QRU0uICBU SVMvUEVNDQogICBpcyBjYXBhYmxlIG9mIGdlbmVyYXRpbmcgdGhlIGNlcnRpZmljYXRlcyB0aGF0 IHlvdSBuZWVkLiAgSm9pbmluZw0KICAgdGhlIEludGVybmV0IGNlcnRpZmljYXRpb24gaGllcmFy Y2h5IGhhcyB0aGUgYmVuZWZpdCBvZiBtYWtpbmcgaXQNCiAgIGVhc2llciB0byB2ZXJpZnkgb3Ro ZXJzJyBtYWlsIGFuZCBmb3IgdGhlbSB0byB2ZXJpZnkgeW91cnMuICBUbw0KICAgam9pbiB0aGUg SW50ZXJuZXQgY2VydGlmaWNhdGlvbiBoaWVyYXJjaHksIHlvdSBtdXN0IHNpZ24gdXAgeW91cg0K ICAgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgKENBKSB1bmRlciBhIFBvbGljeS1sZXZlbCBDZXJ0 aWZpY2F0aW9uDQogICBBdXRob3JpdHkgKFBDQSkuICANCg0KMTENClE6IFdoYXQgaXMgYSBkaXN0 aW5ndWlzaGVkIG5hbWU/DQoNCkE6IEEgZGlzdGluZ3Vpc2hlZCBuYW1lIGlzIGEgaGllcmFyY2hp Y2FsLCBnbG9iYWxseSB1bmlxdWUgbmFtZSB1c2VkDQogICB0byBpZGVudGlmeSBzb21ldGhpbmcg b3Igc29tZW9uZS4gIFJGQyAxMjU1IGFuZCBzZXZlcmFsIE5vcnRoDQogICBBbWVyaWNhbiBEaXJl Y3RvcnkgRm9ydW0gKE5BREYpIGRvY3VtZW50cyBkZXNjcmliZSBob3cgdG8gc2VsZWN0DQogICBh cHByb3ByaWF0ZSBkaXN0aW5ndWlzaGVkIG5hbWVzLiAgVGhlIGRpc3Rpbmd1aXNoZWQgbmFtZSBm b3IgRWFybA0KICAgU2luY2xhaXIgKGEgZmljdGlvbmFsIGNoYXJhY3RlciwgZ2VvZ3JhcGhpY2Fs bHkgZGlzcGxhY2VkKSBtaWdodCBiZQ0KDQogICAgIENvdW50cnk9VVMNCiAgICAgU3RhdGUgb3Ig UHJvdmluY2U9Q0EgDQogICAgIE9yZ2FuaXphdGlvbj1XZXNheXNvIENvcnBvcmF0aW9uDQogICAg IE9yZ2FuaXphdGlvbmFsIFVuaXQ9VHJlZSBQdXNoaW5nIERpdmlzaW9uDQogICAgIENvbW1vbiBO YW1lPUVhcmwgU2luY2xhaXINCg0KMTINClE6IFdoYXQgaXMgYSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSAoQ0EpPw0KDQpBOiBBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IChDQSkgdm91Y2hlcyBm b3IgdGhlIGJpbmRpbmcgYmV0d2Vlbg0KICAgdXNlcnMnIGRpc3Rpbmd1aXNoZWQgbmFtZXMgYW5k IFJTQSBwdWJsaWMga2V5cyB3aXRoaW4gYW4NCiAgIG9yZ2FuaXphdGlvbiBvciBvcmdhbml6YXRp b25hbCB1bml0LiAgVGhlIENBJ3MgZGlzdGluZ3Vpc2hlZCBuYW1lDQogICBpcyB0aGF0IG9mIHRo ZSBvcmdhbml6YXRpb24gb3Igb3JnYW5pemF0aW9uYWwgdW5pdCBhbmQgdXNlcnMnDQogICBkaXN0 aW5ndWlzaGVkIG5hbWVzIGFyZSBjcmVhdGVkIGJ5IHN0YXJ0aW5nIHdpdGggdGhlIENBDQogICBk aXN0aW5ndWlzaGVkIG5hbWUgYW5kIGFkZGluZyBzb21ldGhpbmcgdG8gdW5pcXVlbHkgYW5kDQog ICB1bmFtYmlndW91c2x5IGlkZW50aWZ5IHRoZSB1c2VyLCBsaWtlIGEgY29tbW9uIG5hbWUuDQoN CjEzDQpROiBXaGF0IGRvZXMgYSBQQ0EgZG8gYW5kIGhvdyBhcmUgdGhleSBkaWZmZXJlbnRpYXRl ZD8NCg0KQTogUENBcyB2b3VjaCBmb3IgdGhlIGJpbmRpbmcgYmV0d2VlbiBhIENBJ3MgZGlzdGlu Z3Vpc2hlZCBuYW1lIGFuZA0KICAgUlNBIHB1YmxpYyBrZXkuICBCeSBqb2luaW5nIGEgUENBLCBv dGhlcnMgY2FuIHZlcmlmeSB5b3VyIFBFTQ0KICAgbWVzc2FnZXMgYnkgZm9sbG93aW5nIHRoZSBj ZXJ0aWZpY2F0aW9uIHBhdGggdG8gdGhlIEludGVybmV0DQogICBQb2xpY3ktbGV2ZWwgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgY2VydGlmaWNhdGUgd2l0aG91dCBoYXZpbmcgdG8NCiAgIGhhdmUg cmV0cmlldmVkIHlvdXIgUlNBIHB1YmxpYyBrZXkgdXNpbmcgc2VjdXJlLCBvdXQgb2YgYmFuZA0K ICAgbWVhbnMuICBQQ0FzIG1heSBhbHNvIG1ha2UgQ0EgQ2VydGlmaWNhdGUgUmV2b2NhdGlvbiBM aXN0cyAoQ1JMcykNCiAgIGFuZCBjZXJ0aWZpY2F0ZXMgYXZhaWxhYmxlIGFuZCBwcm92aWRlIG90 aGVyIHNlcnZpY2VzIGZvciBpdHMNCiAgIG1lbWJlcnMuDQoNCiAgIFBDQXMgY2FuIGJlIGRpZmZl cmVudGlhdGVkIGJ5IHRoZSBwb2xpY3kgdGhhdCB0aGV5IGFkdmVydGlzZS4gIFRoZQ0KICAgcG9s aWN5IGluY2x1ZGVzIHRoZSBsZXZlbCBvZiBlZmZvcnQgLS0gYW5kIGFzc29jaWF0ZWQgYXNzdXJh bmNlIC0tDQogICB0aGF0IGEgUENBIHVzZXMgdG8gaW5zdXJlIHRoZSBjb3JyZWN0bmVzcyBvZiB0 aGUgYmluZGluZyBhbmQgdGhlDQogICByZXF1aXJlbWVudHMgdGhleSBwbGFjZSBvbiBDQXMgd2hp Y2ggaXNzdWUgY2VydGlmaWNhdGVzIHVuZGVyIHRoZW0uDQogICBUaGV5IGNhbiBhbHNvIGJlIGRp ZmZlcmVudGlhdGVkIGJ5IHRoZSBvdGhlciBzZXJ2aWNlcyB0aGV5IG9mZmVyDQogICBhbmQgdGhl aXIgcHJpY2UuDQoNCjE0DQpROiBXaGF0IFBDQXMgYXJlIGF2YWlsYWJsZT8NCg0KQTogU2V2ZXJh bCBQQ0FzIGV4aXN0IGFzIHBhcnQgb2YgdGhlIEludGVybmV0IGNlcnRpZmljYXRpb24gaGllcmFy Y2h5LA0KICAgaW5jbHVkaW5nIFBDQXMgYXQgUlNBRFNJIGFuZCBUSVMsIGFuZCBtb3JlIG1heSBj b21lIG9ubGluZSBpbiB0aGUNCiAgIG5lYXIgZnV0dXJlLg0KDQoxNQ0KUTogSG93IG11Y2ggZG9l cyBpdCBjb3N0IHRvIHNpZ24gdXAgdW5kZXIgYSBQQ0E/DQoNCkE6IEluZGl2aWR1YWwgUENBcyB3 aWxsIGhhdmUgdGhlaXIgb3duIHByaWNlIHNjaGVkdWxlcy4gIFNpZ25pbmcgdXANCiAgIHVuZGVy IHRoZSBUSVMgUENBIGlzIGZyZWUgZHVyaW5nIDE5OTMuIA0KDQoxNg0KUTogV2hhdCBpZiBJIGhh dmUgcXVlc3Rpb25zIGFib3V0IFRJUyBQQ0E/DQoNCkE6IFNlbnQgdGhlbSB0byB0aXNwY2EtaW5m b0B0aXMuY29tLg0KDQoxNw0KUTogSXMgdGhlcmUgYSBtYWlsaW5nIGxpc3QgZm9yIFRJUy9QRU0g dXNlcnM/DQoNCkE6IFllcywgaXQncyB0aXNwZW0tdXNlcnNAdGlzLmNvbS4gIFNlbmQgbWFpbCB0 bw0KICAgdGlzcGVtLXVzZXJzLXJlcXVlc3RAdGlzLmNvbSB0byBiZSBhZGRlZCB0byBvciBkZWxl dGVkIGZyb20gdGhlDQogICBsaXN0Lg0KDQoxOA0KUTogV2hhdCBpZiBJIGhhdmUgcXVlc3Rpb25z IGFib3V0IG9yIHByb2JsZW1zIHdpdGggVElTL1BFTT8NCg0KQTogU2VuZCB0aGVtIHRvIHRpc3Bl bS1zdXBwb3J0QHRpcy5jb20uDQoNCjE5DQpROiBDYW4gUEVNIGJlIHVzZWQgd2l0aCBNSU1FPw0K DQpBOiBZZXMuICBUaGUgYm9keSBvZiBQRU0gbWVzc2FnZSwgYXMgZGVmaW5lZCBieSBSRkMgMTQy MSwgY291bGQgYmUNCiAgIHBsYWNlZCBpbnNpZGUgYSBNSU1FIGJvZHkgcGFydCBsYWJlbGxlZCAi YXBwbGljYXRpb24vcGVtLTE0MjEiLiAgSW4NCiAgIGFkZGl0aW9uLCB0aGUgUEVNIHdvcmtpbmcg Z3JvdXAgb2YgdGhlIElFVEYgaXMgd29ya2luZyBvbiBhDQogICBzcGVjaWZpY2F0aW9uIGZvciBh biBpbnRlZ3JhdGlvbiB0aGF0IHdpbGwgYWxsb3cgUEVNIHRvIHRha2UNCiAgIGFkdmFudGFnZSBv ZiB0aGUgc3RydWN0dXJlIGZyYW1ld29yayBwcm92aWRlZCBieSBNSU1FLiAgWW91IG1heSBhc2sN CiAgIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBQRU0gZGV2ZWxvcGVycyBtYWlsaW5nIGxp c3QsDQogICAicGVtLWRldkB0aXMuY29tIi4NCi0tLS0tRU5EIFBSSVZBQ1ktRU5IQU5DRUQgTUVT U0FHRS0tLS0tCg== ------- =_aaaaaaaaaa0-- From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 18:46:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07986; Fri, 29 Oct 93 16:29:18 EDT Received: from uxc.cso.uiuc.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07982; Fri, 29 Oct 93 16:29:17 EDT Received: from dorner.slip.uiuc.edu by uxc.cso.uiuc.edu with SMTP id AA04344 (5.67a/IDA-1.5 for ); Fri, 29 Oct 1993 15:28:55 -0500 Received: from [192.17.5.2] (ldorner2) by dorner.slip.uiuc.edu with SMTP id AA03208 (5.65c/IDA-1.4.4 for ietf-822@dimacs.rutgers.edu); Fri, 29 Oct 1993 15:30:40 -0500 Message-Id: <199310292030.AA03208@dorner.slip.uiuc.edu> X-Sender: sdorner@dorner.slip.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Oct 1993 15:29:54 -0500 To: ietf-822@dimacs.rutgers.edu From: sdorner@qualcomm.com (Steve Dorner) Subject: RE: Re[2]: yet another way to indicate related MIME body parts At 9:00 AM 10/29/93 -0800, Ned Freed wrote: >The message from Steve which you characterized as a entirely accurate precis of >remaining issues stated that inclusion of such a parameter made header-set >worthless. That wasn't what I meant to say. I meant to say that there is very little difference in my mind between: multipart/foo and multipart/header-set; type=foo *ONLY* as far as reducing subtype proliferation. From a "how many subtypes do we have in the world" perspective, "foo" is in either case effectively a multipart subtype. (Whether or not subtype proliferation is bad is of course another question.) But I think you still have the advantage of some sort of hint regarding the first part of the multipart type (though I'm going to concede that this is only true of some sorts of header-sets), and the advantage of not having to repeat the data part just to get alternate representations of the header part. -- 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 Fri Oct 29 19:13:57 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08143; Fri, 29 Oct 93 17:01:35 EDT Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08136; Fri, 29 Oct 93 17:01:31 EDT Received: by brazos.is.rice.edu (AA27459); Fri, 29 Oct 93 16:01:26 CDT Date: Fri, 29 Oct 1993 15:56:08 -0500 (CDT) From: Rick Troth Subject: Re: Query on a nit: Application vs. Text conten-type To: timbl@nxoc01.cern.ch Cc: Dave Crocker , ietf-822@dimacs.rutgers.edu In-Reply-To: <9310291627.AA02356@www3.cern.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I may be way out of line on this, but personally I don't like > the Application/.... bag at all. Firstly, it doesn't mean > "application", it means "other". And one should be wary of > any system which files most things under "other". I think you're right, that it does mean "other". But I also see a subtle hint of "text ---> handled internally" and "application ---> handled externally". Can we emphasize this? Is it even a reality or just my misperception? (and image and audio are two other types handled (sort of) internally) > All data has to be processed by some application. > It is was designed to be a derogatory "application-specific", > meaning "only one application", or "non-standard", or > "proprietory", or "non-rfc", then fair enough but nothing > common and well defined should go into it. > > ... > > Tim Berners-Lee -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 17:12:21 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06170; Fri, 29 Oct 93 14:25:07 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06165; Fri, 29 Oct 93 14:25:02 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H4ORX45RRK000UMF@INFOODS.UNU.EDU>; Fri, 29 Oct 1993 14:24:33 EDT Date: Fri, 29 Oct 1993 14:24:32 -0400 (EDT) From: KLENSIN@infoods.mit.edu Subject: MIME Content subtype reviews agendas To: ietf@cnri.reston.va.us Cc: ietf-smtp@dimacs.rutgers.edu, ietf-822@dimacs.rutgers.edu, mwalnut@cnri.reston.va.us Message-Id: <01H4ORX4P27O000UMF@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@dimacs.rutgers.edu, ietf-smtp@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Summary: Following is the agenda information for the two MIME "Content BOFs" listed on the IETF agenda for 0930 on Tuesday and 1600 on Wednesday. These are not BOFs in the usual sense, but ad hoc review efforts that the Applications Area directors are convening in an attempt to see if we can get convergence on several overlapping or controversial proposals before we have interoperability problems resulting from differently profiled MIME applications. This is not a BOF, nor are these content subtypes work items of any WG, although one possible outcome would be a conclusion that WGs should be formed to address one or more of these topics. ------------ Several proposals have emerged for MIME subtypes and applications that may have broad implications for the IETF community. The Applications Area Directors have concluded that a specific review and discussion on three of these would be useful to try to resolve conflicts among proposals and expose any issues that have not arisen in mailing list discussion. Proponents of approaches types that seem to be in conflict are expected to be able to identify differences among approaches and relative strengths and weaknesses of their own. Proponents of alternatives not yet on the table are encouraged to get documents posted immediately to the archive at IS.Internic.NET. The intent of these reviews is to determine whether proposals of these types belong on the standards track and, if possible, to begin to identify a consensus about the right approach for those proposals. As is usual with WG meetings, anyone intending to participate in the discussions is expected to have reviewed the relevant documents prior to coming to these sessions. While single meeting slots have been scheduled, these should be considered as separate reviews, to occur at the times specified. Note that the documents listed were current at the time these notes were written. They should be linked (soon) from the /pub/current-ietf-docs/app/mimecont directory at IS.InterNIC.NET. Later versions may appear in that directory. ------ Session I. Tuesday, November 2, 0930. This session will be multicast. 1. Full SGML over MIME and SGML introduction (0930 - 1015) Current document: draft-levinson-mime-sgml-00.txt (I'm trying to get a good tutorial on SGML posted, but am awaiting reproduction permission. Check for sgml-tutorial.ps in the InterNIC directory.) 2. MIME multipart structuring: Header-sets and references (1020 - 1105) Current documents: draft-crocker-headerset-00.txt, .ps draft-moore-mime-reference-00.txt 3. Structured information and personal contact info (1110 - 1200) Current documents: draft-crocker-stif-00.txt, .ps draft-crocker-pci-00.txt, .ps draft-adie-shave-00.txt, .ps draft-adie-spci-00.txt, .ps draft-vaudreuil-mime-sig-00.txt ----- Session II, Wednesday, November 3, 1600 1. Delivery reports and notifications (1600 - 1640) Note: this topic raises SMTP [transport] service extension issues also. Current documents: draft-moore-mime-delivery-00.txt draft-moore-smtp-drpt-00.txt draft-vaudreuil-mime-delivery-00.txt 2. Specification of presentation direction for text/plain and languages whose natural order is not left-to-right. (1640 - 1720) Current documents: draft-nussbacher-mime-direction-01.txt Slot A, item III. Macintosh file transmission with MIME (1720 - 1800) Current documents: draft-faltstrom-macmime1-00.txt draft-faltstrom-macmime2-00.txt ------ The other two current hot issues--proposals for binary transport and streaming in SMTP are not on the agenda for this IETF. From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 18:42:40 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07737; Fri, 29 Oct 93 16:07:52 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07733; Fri, 29 Oct 93 16:07:50 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA29527; Fri, 29 Oct 93 16:07:31 -0400 Date: Fri, 29 Oct 93 16:07:31 -0500 From: Dana S Emery To: Rick Troth Subject: Re: Text/enriched ambiguity Cc: John Gardiner Myers , ietf-822@dimacs.rutgers.edu Message-Id: In-Reply-To: Your message of Fri, 29 Oct 1993 11:16:40 -0500 (CDT) Content-Type: TEXT/plain; charset=US-ASCII > > example is that there is no matching or > > > > Whoah... hang on. WHY is this a problem? violation of scope. a establishes a new state in the document which is required to nest within the state established before it. ... but not ... . Admittedly some commands would function well if they implied a cancel as in: ... ... ... but there would be no way for a dumb text/enriched parser which didnt recognize the setcolor command to parse properly, unless we introduced new syntax, and this would impact all present engines, so it may not be a good idea: <> IMHO the spec should have provided an intrinsic typing in order to allow the parser to classify even anonymous commands: <> ... <> <<>> parameters, hide em if dondo<<>> The purpose being to provide a foundation for a robust parser. -- dana s emery From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 21:09:53 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08547; Fri, 29 Oct 93 18:07:39 EDT Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08543; Fri, 29 Oct 93 18:07:38 EDT Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <12002(2)>; Fri, 29 Oct 1993 15:07:06 PDT Received: by holmes.parc.xerox.com id <16134>; Fri, 29 Oct 1993 15:06:57 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41 via MS.5.6.holmes.parc.xerox.com.sun4_41; Fri, 29 Oct 1993 15:06:47 -0700 (PDT) Message-Id: Date: Fri, 29 Oct 1993 15:06:47 PDT Sender: Bill Janssen From: Bill Janssen To: timbl@nxoc01.cern.ch Subject: Re: Query on a nit: Application vs. Text conten-type Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9310291627.AA02356@www3.cern.ch> References: <9310291627.AA02356@www3.cern.ch> Excerpts from ext.ietf-822: 29-Oct-93 Re: Query on a nit: Applic.. Tim Berners-Lee@www3.cer (2676) > If MIME puts HTML under > "application" but "enriched" under "text", then the initial > part of the type has become meaningless. > Tim Berners-Lee We went through all this on the MIME list almost two years ago. The conclusion was that the initial part of the type is indeed meaningless. The only interesting thing to do with MIME types is to treat each / pair as a single specific type. Bill From owner-ietf-822@dimacs.rutgers.edu Fri Oct 29 21:18:50 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08662; Fri, 29 Oct 93 18:42:35 EDT Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08658; Fri, 29 Oct 93 18:42:33 EDT Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Sat, 30 Oct 93 08:42:22 +1000 Date: Sat, 30 Oct 93 08:42:21 EST From: rhys@cs.uq.oz.au Message-Id: <9310292242.AA13494@client> To: jgm+@cmu.edu, troth@rice.edu Subject: Re: Text/enriched ambiguity Cc: ietf-822@dimacs.rutgers.edu >> The problem with the >> >> >> >> example is that there is no matching or >> > > Whoah... hang on. WHY is this a problem? > > I've always seen these as "commands" and coded accordingly. >If you get a and then a , fine. If you get a >and never encounter the , still fine. Maybe, maybe not. In a stack-based parser, this could be a real pain in the neck. It also defeats auto-correction schemes to some extent. Have a look at the metamail richtext code which I added auto-correction to in the lexical analysis: it attempts to rebalance commands if the user stuffed something up (e.g. through hand-composition). Unless there is a matching command or a different way to indicate commands that don't need a , auto-correction and stack-based parsers will be defeated. For the colorentry example, I can't see anything wrong with (to define two colours): red 255 0 0 blue 0 0 255 The extra bracketing cited by someone else seems unnecessary to me. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 00:39:54 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13111; Fri, 29 Oct 93 23:02:41 EDT Received: from PO3.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13107; Fri, 29 Oct 93 23:02:39 EDT Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id XAA13310; Fri, 29 Oct 1993 23:02:35 -0400 Received: via switchmail; Fri, 29 Oct 1993 23:02:34 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 23:01:44 -0400 (EDT) Received: from hogtown.andrew.cmu.edu via qmail ID ; Fri, 29 Oct 1993 23:01:42 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Fri, 29 Oct 1993 23:01:40 -0400 (EDT) Message-Id: Date: Fri, 29 Oct 1993 23:01:40 -0400 (EDT) From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: Query on a nit: Application vs. Text conten-type In-Reply-To: References: <9310291627.AA02356@www3.cern.ch> Beak: is Not The important distinction between the application and text primary types is whether or not it is appropriate to show the user the "raw" version of the data if the type is not recognized. Wording to this effect is in section 4, paragraph 4 and appendix A requirement 4 of RFC 1521. It would seem to me that HTML really does belong under the "text" top-level content type. -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 02:14:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13922; Sat, 30 Oct 93 01:58:49 EDT Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13918; Sat, 30 Oct 93 01:58:47 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4P4I2KVLC9BVCNK@INNOSOFT.COM>; Fri, 29 Oct 1993 22:58:29 PST Date: Fri, 29 Oct 1993 22:56:22 -0800 (PST) From: Ned Freed Subject: RE: Re[2]: yet another way to indicate related MIME body parts In-Reply-To: Your message dated "Fri, 29 Oct 1993 09:24:24 -0500" <199310291425.AA02505@dorner.slip.uiuc.edu> To: sdorner@qualcomm.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H4P9VBPFKQ9BVCNK@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT > I don't think header-set is an appropriate whipping boy for the slowness of > the MIME standards & implementation process, though it may be the current > bottleneck in a few cases. I know the MacMIME proposal has been > languishing since long before the header-set discussion began. Ned at one > point indicated that he thought it would be a year before he would be > interested in supporting MacMIME, and that was when the proposal was > multipart/appledouble, before header-set was suggested. I don't believe I ever said this. What I said was that my most optimistic estimate of the time it would take to get MacMIME through the process, rounded up to the next release of our product, would be about a year. Given the time when I originally this statement, I may have been optimistic. Ned From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 13:07:29 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15423; Sat, 30 Oct 93 12:29:27 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15419; Sat, 30 Oct 93 12:29:25 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H4PI56HW0G000V9J@INFOODS.UNU.EDU>; Sat, 30 Oct 1993 12:28:44 EDT Date: Sat, 30 Oct 1993 12:28:44 -0400 (EDT) From: John C Klensin Subject: Re: yet another way to indicate related MIME body parts In-Reply-To: <9310291639.AA02376@www3.cern.ch> To: timbl@nxoc01.cern.ch Cc: ietf-822@dimacs.rutgers.edu, elevinso@accurate.com, conklin@ivory.educom.edu Message-Id: <751998524.188783.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: > Whatever happened to simple, generic arrangements? :-) ISO WGs getting out of their depth. The combination of generality -- the attempt to cover all cases, even some that will never occur and others that are only half-thought-out -- and the complexity that results from that particular form/interpretation of generality is, in my experience, _the_ most common symptom of groups who are expert in one area thinking that gives them expertise in all other areas that touch on it. ISO WGs are particularly vunerable to this, since the rules permit a group that has developed a standard (and may have been just the right selection of experts for that standard) to then start generating NWIs for things that bear on that standard but that have no technical relationship to it at all. To the degree to which IETF, on average, produces better products, I believe it is in part because we shut WGs down and create new ones --with enhanced opportunities for new leadership, membership and perspectives-- when new programmes of work come along, rather than permitting virus-like expansion of roles and unfocused programmes. When we have failed to do that, we, too, end up with ill-considered attempts at generalization that tend to result in excess complexity and leaving "hooks" for things that more closely resemble round holes for square pegs when those "things" actually evolve to the point where they can be defined. If anyone thinks I'm referring to any specific efforts or suggestions here, in either the email or the IIA work areas, well, to quote and old proverb, "if the shoe fits, wear it". --john-the-depressed From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 14:07:29 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19085; Sat, 30 Oct 93 13:37:46 EDT Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19081; Sat, 30 Oct 93 13:37:45 EDT Received: from rita-blanca.is.rice.edu by is.rice.edu (AA05367); Sat, 30 Oct 93 12:37:42 CDT Received: by rita-blanca.is.rice.edu (AA02530); Sat, 30 Oct 93 12:37:40 CDT Date: Sat, 30 Oct 1993 12:32:23 -0500 (CDT) From: Rick Troth Subject: Re: Text/enriched ambiguity To: John Gardiner Myers Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <0goLWsa00WBwEx1McB@andrew.cmu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > One of the "simplifications" of text/enriched over text/richtext was > that there are no without matching > > -- > _.John G. Myers Internet: jgm+@CMU.EDU > LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up Well that's the key right there. But the problem with Rhys' red 255 0 0 blue 0 0 255 is how do you *know* that colorentries won't someday include some other compensating parameter? And even if we assume (safely, I'm sure you'll agree) that primary colors will always be composed of R, G & B, we have to use a different mechanism to parse a colorentry than to parse something else. Well no ... you could have some table that says "colorentries have exactly three parameters", but that doesn't work for things that have variable numbers of parameters. Ugh! -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 14:57:30 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19111; Sat, 30 Oct 93 13:48:00 EDT Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19106; Sat, 30 Oct 93 13:47:52 EDT Received: from rita-blanca.is.rice.edu by is.rice.edu (AA05566); Sat, 30 Oct 93 12:47:43 CDT Received: by rita-blanca.is.rice.edu (AA02536); Sat, 30 Oct 93 12:47:41 CDT Date: Sat, 30 Oct 1993 12:37:47 -0500 (CDT) From: Rick Troth Subject: Re: Text/enriched ambiguity To: rhys@cs.uq.oz.au Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9310292242.AA13494@client> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > I've always seen these as "commands" and coded accordingly. > >If you get a and then a , fine. If you get a > >and never encounter the , still fine. > > Maybe, maybe not. In a stack-based parser, this could be a real > pain in the neck. It also defeats auto-correction schemes to some > extent. ... > Unless there is a matching command or a different way to indicate > commands that don't need a , auto-correction and stack-based parsers > will be defeated. These are valid points. Please consider, and let me know what you come up with, the idea of enhancing a stack based-parser. I agree about the usefulness of auto-correction, and my suggestion would complicate that ... slightly. All you need is a bit somewhere saying "this must be matched within context" or not. > For the colorentry example, I can't see anything wrong with (to define > two colours): > > red 255 0 0 blue 0 0 255 I'd say try, red 255 0 0 blue 0 0 255 > The extra bracketing cited by someone else seems unnecessary to me. Above, I used the / method to delimit the colorentries. I'm not completely happy with that because to me it is less generic than allowing commands without matching /commands. See for yourself: it's easier to take the string delimited by angle brackets and act on the "verb" (which may or may not have parameters) than to switch into and out of "colorentry modification mode". > Cheers, > > Rhys. -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 12:37:28 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15388; Sat, 30 Oct 93 12:15:37 EDT Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15384; Sat, 30 Oct 93 12:15:36 EDT Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA13393; Sat, 30 Oct 93 12:15:24 -0400 Date: Sat, 30 Oct 93 12:15:25 -0500 From: Dana S Emery To: rhys@cs.uq.oz.au Subject: Re: Text/enriched ambiguity Cc: ietf-822@dimacs.rutgers.edu Message-Id: In-Reply-To: Your message <9310292242.AA13494@client> of Sat, 30 Oct 93 08:42:21 EST Content-Type: TEXT/plain; charset=US-ASCII > red 255 0 0 blue 0 0 255 what would happen when some nincompoop mucks it up as in: red 255 0 0 blue 0 0 255 The issue being how to prevent the parameters from being parsed as if they were text (assuming that to be desirable). > The extra bracketing cited by someone else [me :-)] seems > unnecessary to me. that extra bracketing was not meant to be taken literally, later on in it I sugested a 2 character bracketing system: <@...> <#...> but other forms of bracketing would also serve: {...} [...] <...> the point being to describe a self-typing token. From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 14:37:29 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19161; Sat, 30 Oct 93 13:52:53 EDT Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19157; Sat, 30 Oct 93 13:52:52 EDT Received: from rita-blanca.is.rice.edu by is.rice.edu (AA05652); Sat, 30 Oct 93 12:52:50 CDT Received: by rita-blanca.is.rice.edu (AA02545); Sat, 30 Oct 93 12:52:49 CDT Date: Sat, 30 Oct 1993 12:50:03 -0500 (CDT) From: Rick Troth Subject: Re: Query on a nit: Application vs. Text conten-type To: Bill Janssen Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > If MIME puts HTML under > > "application" but "enriched" under "text", then the initial > > part of the type has become meaningless. > > > Tim Berners-Lee > > We went through all this on the MIME list almost two years ago. The Doncha just hate how these things come back? ;-) > conclusion was that the initial part of the type is indeed meaningless. > The only interesting thing to do with MIME types is to treat each > / pair as a single specific type. I don't do that. I have one MUA which isn't capable (for reasons beyond MIME) of processing things in parallel. It treats *everything* of type "MULTIPART/" the same. I for one would appreciate it if we could retain some sense in the grouping of secondary types under appropriate primary types. > Bill -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 17:07:30 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19632; Sat, 30 Oct 93 17:00:49 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19628; Sat, 30 Oct 93 17:00:48 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H4PI56HW0G000V9J@INFOODS.UNU.EDU>; Sat, 30 Oct 1993 17:00:11 EDT Date: Sat, 30 Oct 1993 17:00:10 -0400 (EDT) From: John C Klensin Subject: MIME content type reviews To: ietf-822@dimacs.rutgers.edu Message-Id: <752014810.132783.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: I've just posted a new version of the agenda to the InterNIC repository. It is in /incoming/current-ietf-docs/app.mimecont.agenda-02.txt right now, and will be in /pub/current-ietf-docs/app/minecont/agenda-02.txt as soon as it gets moved over. There are two significant changes so far relative to the version posted to the list: (1) The identification information for the Levinson draft was wrong. it is draft-levinson-sgml-00.txt (2) The promised SGML tutorial is now online, with the permission of the author. It is in /incoming/current-ietf-docs/app.iia.tei-sgml.txt and .ps now, and will be in /pub/current-ietf-docs/app/iia/tei-sgml-tutorial.txt and .ps when moved. There may be a link from the mimecont directory. We are negotiating for permission to move toward publication of the latter as an informational RFC, but, for the moment.... The permanent repository for this document is (among other places) sgml1.ex.ac.uk, /tei/p2/drafts/p2sg.ps and p2sg.doc. From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 16:37:30 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19563; Sat, 30 Oct 93 16:27:53 EDT Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19559; Sat, 30 Oct 93 16:27:51 EDT Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H4PI56HW0G000V9J@INFOODS.UNU.EDU>; Sat, 30 Oct 1993 16:27:15 EDT Date: Sat, 30 Oct 1993 16:27:15 -0400 (EDT) From: John C Klensin Subject: Re: Text/enriched ambiguity In-Reply-To: To: troth@rice.edu Cc: rhys@cs.uq.oz.au, ietf-822@dimacs.rutgers.edu Message-Id: <752012835.39783.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: Observation from the committee on spotting of square wheels.... Going back the the parent SGML syntax might be instructive here. While any of the methods cited could be made to work with a properly-defined DTD, the most obvious would be either: red 255 0 0 blue 0 0 255 or 255 0 0 0 0 255 In the first case, the parsing rule is that "colorentry" gets one or more subelements: any other type of subelements are bogus. And each "c" element consists of a reserved-string color name, followed by its parameters. In the second case, one has to reserve the color names into element names--probably a disadvantage if you wanted to be able to name "green" but otherwise more a matter of aesthetics than anything else. In either case, it might be sensible to permit/require eliminating the end-tags on the color elements, so we would actually see: red 255 0 0 blue 0 0 255 or 255 0 0 0 0 255 Not that these schemes are robust against later needing to add another parameter or two to the colors (intensity or brightness, perhaps) and, modulo the "yellow" issue to adding new colors. And it isn't necessary to invent trick delimiters that would have to be handled in a special way in the lexical mechanisms. This is not a suggestion that this be adopted for text/enriched, or that it is the best alternative, only an attempt to populate the data space with an approach with which there is successful operational experience. --john From owner-ietf-822@dimacs.rutgers.edu Sat Oct 30 20:07:32 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19921; Sat, 30 Oct 93 19:23:26 EDT Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19917; Sat, 30 Oct 93 19:23:24 EDT Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Sun, 31 Oct 93 09:23:21 +1000 Date: Sun, 31 Oct 93 09:23:20 EST From: rhys@cs.uq.oz.au Message-Id: <9310302323.AA25764@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity > is how do you *know* that colorentries won't >someday include some other compensating parameter? And even if >we assume (safely, I'm sure you'll agree) that primary colors >will always be composed of R, G & B, we have to use a different >mechanism to parse a colorentry than to parse something else. >Well no ... you could have some table that says "colorentries >have exactly three parameters", but that doesn't work for things >that have variable numbers of parameters. Ugh! This discussion started, I believe, with a question as how to best handle the insides of a block. Such blocks are explicitly intended to contain application-specific information in a format that is not yet defined. I'd expect that the example would be "wrapped up" in a block. So, trying to define a rigid format for such blocks would be premature, until such time as someone feels the need for . However, if a consistent mechanism for blocks is required, it shouldn't be difficult to come up with one. e.g. block = 1*(tag [ params ]) tag = identifier / number / string params = "{" block "}" So, the color example would be: red{255 0 0} blue{0 0 255} This structure can be extended with arbitrary levels of nesting as necessary, and is pretty close to the way most tagged file formats are designed to accomodate arbitrary future extensions. But, I'm not sure I'd like to see this adopted until there is a real need for it, which at the moment I can't see. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Sun Oct 31 07:07:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26558; Sun, 31 Oct 93 06:41:32 EST Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26554; Sun, 31 Oct 93 06:41:30 EST Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Sun, 31 Oct 93 06:41:25 EST Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Sun, 31 Oct 93 06:42:18 EST 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; Sun, 31 Oct 1993 06:42:17 -0500 (EST) Message-Id: <0gouGNC0M2UDIFZAcy@thumper.bellcore.com> Date: Sun, 31 Oct 1993 06:42:17 -0500 (EST) From: Nathaniel Borenstein To: rhys@cs.uq.oz.au, Dana S Emery Subject: Re: Text/enriched ambiguity Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: References: > that extra bracketing was not meant to be taken literally, later > on in it I sugested a 2 character bracketing system: Sigh. The design of text/enriched has continually gotten stuck, I believe, on the conflict between power and simplicity. I also believe this is inevitable, given the design goals; we're trying to choose a single point on a contiuum where simplicity and power trade off. There's almost certainly no absolutely "right" point on that continuum to be. I'm generally inclined to favor simplicity over power, mostly because there's no shortage of arbitrarily powerful rich text languages out there. So I guess I would prefer see eliminated entirely, thus simplifyinging the spec, rather than see additional complexity added to the basic command syntax. Of course, I don't think this is an either/or choice, that's just my take on which direction I'd rather move if we had to move in one direction or another. In other words, I think that, inevitably, text/enriched is neither powerful enough to do everything nor simple enough to satisfy everyone, but that if we were to change it from its current spec, we'd be better off simplifying even further at the expense of power. I'm curious whether this basic attitude is shared by the other participants in this discussion. -- Nathaniel From owner-ietf-822@dimacs.rutgers.edu Sun Oct 31 13:37:40 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01414; Sun, 31 Oct 93 13:28:34 EST Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01410; Sun, 31 Oct 93 13:28:33 EST Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA07298; Sun, 31 Oct 93 13:28:30 -0500 Date: Sun, 31 Oct 93 13:28:29 -0500 From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity Message-Id: In-Reply-To: Your message <0gouGNC0M2UDIFZAcy@thumper.bellcore.com> of Sun, 31 Oct 1993 06:42:17 -0500 (EST) Content-Type: TEXT/plain; charset=US-ASCII > There's almost certainly no absolutely "right" point on > that continuum to be. well, perhaps, but if we pretend to have an upwardly extensible design then a certain minimum complexity seems necessary, too bad exactly what that should comprise has eluded us. rhys> I'd expect that the example would be rhys> "wrapped up" in a block... xxx becomes {a..z} Given that context, any of the following 1 {<8bitRGB> red 255 0 0... } 2 {<8bitRGB> red 255 0 0...} 3 {<8bitRGB> red 255 0 0... } 4 {<8bitRGB> red 255 0 0...} meets my concerns regarding engines which are ignorant of the particular parameter. My (weak) personal preference between them would be 2, but I wouldnt be unhappy making a parser for 1, 3, or 4. > In other words, I think that, inevitably, text/enriched > is neither powerful enough to do everything nor simple > enough to satisfy everyone, but that if we were to > change it from its current spec, we'd be better off > simplifying even further at the expense of power. I dont think the baby is dead yet, but the bath water is getting cold, lets see if we cant get it changed? -- dana s emery From owner-ietf-822@dimacs.rutgers.edu Sun Oct 31 17:07:42 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02526; Sun, 31 Oct 93 17:01:41 EST Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02522; Sun, 31 Oct 93 17:01:35 EST Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA19166; Sun, 31 Oct 93 23:01:23 +0100 Message-Id: <9310312201.AA19166@nada.kth.se> To: Dana S Emery Cc: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity In-Reply-To: Your message of "Sun, 31 Oct 1993 13:28:29 EST." Date: Sun, 31 Oct 1993 23:01:22 +0100 From: Patrik Faltstrom Dana S Emery writes: >rhys> I'd expect that the example would be >rhys> "wrapped up" in a block... > > xxx > >becomes > > {a..z} Just a detail: I would like the characters used for separating syntactic blocks be ASCII characters not used as different glyphs in the ISO-646 series of character sets. I.e. the '{', '[', '}' and ']' is such characters. I do know that the 646 character sets should never be used in MIME messages, but during the tranision phase anything can happen, including confusing messages from people who are trying ot read or create MIME messages by hand. So, choose '<', '>', '(' or ')', but not '{', '}', '[' or ']'. Please... paf From owner-ietf-822@dimacs.rutgers.edu Sun Oct 31 18:37:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02783; Sun, 31 Oct 93 18:17:17 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02779; Sun, 31 Oct 93 18:17:15 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Mon, 1 Nov 93 09:17:13 +1000 Date: Mon, 1 Nov 93 09:17:12 EST From: rhys@cs.uq.oz.au Message-Id: <9310312317.AA14148@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity >to be. I'm generally inclined to favor simplicity over power, mostly >because there's no shortage of arbitrarily powerful rich text languages >out there. So I guess I would prefer see eliminated entirely, I'm certainly in favour of simplicity also. But, I think I'd still like to have some mechanism to say "don't display this because it consists of commands for changing viewer configuration". Thus, we have a single mechanism to "wrap up" possible future extensions like the "colorentry" example in a way that will maintain backwards-compatibility: i.e. older implementations will simply ignore the enclosed text. Even if we have no extensions in mind at the moment, leaving a hole for them would be a good idea, IMHO. Whether this should be called "", "", "", or something else is another issue. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Sun Oct 31 23:39:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07998; Sun, 31 Oct 93 23:15:45 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07994; Sun, 31 Oct 93 23:15:43 EST Received: by brazos.is.rice.edu (AA11272); Sun, 31 Oct 93 22:15:34 CST Date: Sun, 31 Oct 1993 22:05:04 -0600 (CST) From: Rick Troth Subject: Re: Text/enriched ambiguity To: rhys@cs.uq.oz.au Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9310312317.AA14148@client> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > I'm generally inclined to favor simplicity over power, ... > > I'm certainly in favour of simplicity also. Amen! > But, I think I'd still like > to have some mechanism to say "don't display this because it consists of > commands for changing viewer configuration". I'd like to see that too. But I say we already have it. This is why I like the scheme. If a parser recognizes it, great. If not, it still won't accidentally show-up on the user's screen. There was a problem with an HTML document recently. I don't remember if we discussed it here, or if I heard it somewhere else. There was a like like I am not an authority on such-and-such and some parser failed to interpret the leaving out the word "not". Someone who *was* an authority on whatever it was read the disclaimer as I am an authority on such-and-such and was miffed to say the least. The opposite could very well happen. It is arguable that any SGML-ish parser should ignore commands it doesn't understand, passing the text unmodified, in which case you could say that red 255 0 0 *must* be result in "red 255 0 0" being displayed as part of the message. So ... I say, all commands should be what's inside the angle brackets, as a general rule. (there are always exceptions) > Cheers, > > Rhys. -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 00:09:01 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08210; Sun, 31 Oct 93 23:42:19 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08206; Sun, 31 Oct 93 23:42:17 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Mon, 1 Nov 93 14:41:58 +1000 Date: Mon, 1 Nov 93 14:41:57 EST From: rhys@cs.uq.oz.au Message-Id: <9311010441.AA08781@client> To: troth@rice.edu Subject: Re: Text/enriched ambiguity Cc: ietf-822@dimacs.rutgers.edu > I'd like to see that too. But I say we already have it. > > This is why I like the > > Leaving aside the need to determine what commands don't need a balancing command, I may just point out that this will defeat another of my auto-correction schemes: if I am parsing a command name and I encounter a whitespace character, I assume that the '>' was left out or truncated in some fashion, and I insert it myself. This is in the interests of minimising the number of characters that are skipped over to find a matching '>' when something goes wrong. I could no longer make this assumption with commands such as yours. Maybe my lexical analyser is just a little too paranoid. :-) >The opposite could very well happen. It is arguable that any >SGML-ish parser should ignore commands it doesn't understand, >passing the text unmodified, in which case you could say that > > red 255 0 0 > > *must* be result in "red 255 0 0" being >displayed as part of the message. This is the default behaviour for text/enriched at the moment, so we don't have the SGML/HTML problem. It's also why we need a general command like , so we can wrap up "viewer directives" like so: red 255 0 0 Then, a parser that doesn't understand can say "I don't know what this is, but I can safely drop it". Maybe my previous message wasn't very clear, but this is what I was getting at. Now, since there is only one mechanism to indicate where viewer directives occur, we can invent a different syntax for blocks if we like. To extend my previous example, and using '()' instead of '{}': colorentry(red(255 0 0) blue(0 0 255)) But, I am still unconvinced we should define such a syntax now, but rather say that is where it will happen and that we'll leave it until experimentation suggests what syntax is best. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 03:09:05 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09391; Mon, 1 Nov 93 02:48:16 EST Received: from world.std.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09387; Mon, 1 Nov 93 02:48:15 EST Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA19894; Mon, 1 Nov 1993 02:48:08 -0500 Message-Id: <199311010748.AA19894@world.std.com> To: Internet Message Extensions Cc: beast@world.std.com Subject: comment on draft-vandreuil-mime-sig-00.txt Date: Mon, 01 Nov 1993 02:48:07 -0500 From: "Beast (Donald E. Eastlake 3rd)" It seems to me that the attributes should have a much more structured form. For example, instead of Telephone and Fax, I would like to see Phone-work, Phone-home, Phone-fax, and Phone-beeper with Phone-X- allowed. These would all mean that the value field was really a phone number. Similarly, instead of just Address, how about Postal-work, Postal-home, with Postal-X- allowed. Instead of PEM_Cert, there should probably be Certificate-PEM and Certificate-PGP. Etc. It should be text/signature rather than application/signature. I haven't looked at all the other proposals for personal infrmation but I hope these comments will be taken as applicable to them as well. Donald *+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+-+*+- Donald E. Eastlake, III 1-508-486-6577(w) beast@world.std.com PO Box N, MIT Branch PO dee@lkg.dec.com Cambridge, MA 02139 USA 1-508-287-4877(h) From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 03:39:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09382; Mon, 1 Nov 93 02:40:38 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09378; Mon, 1 Nov 93 02:40:36 EST Received: by brazos.is.rice.edu (AA14954); Mon, 1 Nov 93 01:40:35 CST Date: Mon, 1 Nov 1993 01:18:43 -0600 (CST) From: Rick Troth Subject: file transfer in particular To: ietf-822@dimacs.rutgers.edu Cc: troth@rice.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My own view on the whole matter of header sets and object|part attributes is tainted. I have this tool, and a protocol to support it, which sometimes falls back upon mail, in which case "mail" must be MIME. This tool is Internet SENDFILE and is described in RFC 1440. Something completely vague in the RFC though central to the idea is that a "meta file" accompany the file being sent. This metafile is nothing more or less than a set of attributes describing the file and suggesting what exactly the recipient might want to do with it. Now "on the wire" (over TCP) the metafile is embedded in the commands sent from client to server. But what do you do when you fall back to mail? For now, when 'sendfile' can't connect directly via IP, it punts to mail (MIME) using Application/octet-stream. The attributes listed in the metafile are overloaded on the Content- Type header line. It would be better (perhaps) if the metafile were sent as a separate part of Content-Type: Application/sift. I've been using Application/octet-stream because it was already defined. I had hoped that one of these other schemes we've been discussing might do what I'm looking for, but I don't see it. So I'm tempted to pursue getting Application/sift (or maybe Application/sendfile or Application/uft) registered. Thoughts? Here's what it would look like: ... other header lines ... Content-Type: Application/sift; boundary=SIFTBOUNDARY ... other header lines ... --SIFTBOUNDARY Content-Transfer-Encoding: ASCII type=a name=some.example.file date=1993.11.01 01:30:00 --SIFTBOUNDARY Content-Transfer-Encoding: ASCII This then is the body (data) of the file. In this particular case, the file is "Type A" (plain text) and happens to be sent as plain text. Generally I prefer Base 64 for the body, and plain text for the metafile, which speaks all the more for registering this mechanism as its own type so that it would be known and users wouldn't get a mixture of encoding AND get an "unknown" MIME object. --SIFTBOUNDARY-- The metafile looks (intentionally) like UNIX environment strings. In the "on the wire" mode, the equals sign is replaced with a blank space. Maybe the MIME-ified flavour should look the same. So ... the question is, should I continue overloading Content-Type: Application/octet-stream; type=A; name=whatever, etc, or should there be this two-part thing via multipart? -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 09:38:31 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11230; Mon, 1 Nov 93 09:22:36 EST Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11226; Mon, 1 Nov 93 09:22:33 EST Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 1 Nov 93 09:22:27 EST Received: by guppylake.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Mon, 1 Nov 93 09:16:55 EST 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, 1 Nov 1993 09:16:55 -0500 (EST) Message-Id: Date: Mon, 1 Nov 1993 09:16:55 -0500 (EST) From: Nathaniel Borenstein To: troth@rice.edu, rhys@cs.uq.oz.au Subject: Re: Text/enriched ambiguity Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311010441.AA08781@client> References: <9311010441.AA08781@client> This discussion seems to have reaffirmed the utility of (or something like it), but we still haven't resolved the issue of syntax inside a ... block. Should a simple text/enriched process read blindly until the , or should it parse for text/enriched structures, check for nesting, etc.? Alas, I think there are good arguments both ways.... From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 13:38:00 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17323; Mon, 1 Nov 93 13:18:03 EST Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17319; Mon, 1 Nov 93 13:18:02 EST Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA17872; Mon, 1 Nov 93 13:17:57 -0500 Date: Mon, 1 Nov 93 13:17:57 -0500 From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity Message-Id: In-Reply-To: Your message of Mon, 1 Nov 1993 09:16:55 -0500 (EST) Content-Type: TEXT/plain; charset=US-ASCII > we still haven't resolved the issue of syntax inside a > ... block. > Should a simple text/enriched process read blindly until > the I would think yes, I dont see any justification for an ignorant parser to attempt to makes sense of the internal format, but I may be taking a simplistic view, hm, if there were any possibility of nested 's, (perhaps as a result of docs within docs) .... ... .... then we would be challanged to parse the unknown semantic gahd, what a zoo. > Alas, I think there are good arguments both ways.... After all the previous discussion, perhaps its time for a (hopefully succinct) restatement of positions, I will take the liberty of posing the Q: Why would ignorable_param_data_block be unfortunate? -- dana s emery From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 15:07:54 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18664; Mon, 1 Nov 93 15:04:07 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18660; Mon, 1 Nov 93 15:04:04 EST Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15365; Mon, 1 Nov 93 12:03:39 -0800 Message-Id: <9311012003.AA15365@Mordor.Stanford.EDU> To: "Beast (Donald E. Eastlake 3rd)" Cc: Internet Message Extensions Subject: Re: comment on draft-vandreuil-mime-sig-00.txt Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 01 Nov 93 02:48:07 -0500. <199311010748.AA19894@world.std.com> Date: Mon, 01 Nov 93 12:03:39 -0800 From: Dave Crocker X-Mts: smtp Donald, I'd be interested in your views on PCI, as a mechanism for subsuming the signature function. d/ From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 15:37:54 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18604; Mon, 1 Nov 93 14:59:50 EST Received: from Mordor.Stanford.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18600; Mon, 1 Nov 93 14:59:48 EST Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15258; Mon, 1 Nov 93 11:59:28 -0800 Message-Id: <9311011959.AA15258@Mordor.Stanford.EDU> To: "Loux, Greg" Cc: Electronic Data Interchange Issues , ietf-822@dimacs.rutgers.edu Date: Mon, 01 Nov 93 11:59:28 -0800 From: Dave Crocker X-Mts: smtp Subject: Re: FW: EDI over Internet Phone: +1 408 246 8253; fax: +1 408 249 6205 In-reply-to: Your message of 01 Nov 93 09:35:09 -0400. Fcc: outbox -------- Folks, Sorry for the typo and the ensuing retrieval problems. ---- Included message: I've placed the following documents into: ds.internic.net:/pub/ietf-current-docs/app/mimecont This part is correct. 1. app-mimecont-crocker-edix12.00.[ps,txt] this should be: app-mimecont-crocker-edix12-00.[ps,txt Added some intro text and listing of the candidate parameters, per text provided by Tom Jones. 2. app-mimecont-crocker-headerset.01.[ps,txt] and this should be app-mimecont-crocker-headerset-01.[ps,txt] Has the /alternative text. Dave From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 17:07:54 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19608; Mon, 1 Nov 93 16:43:54 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19604; Mon, 1 Nov 93 16:43:52 EST Received: by brazos.is.rice.edu (AA27535); Mon, 1 Nov 93 15:43:47 CST Date: Mon, 1 Nov 1993 15:38:58 -0600 (CST) From: Rick Troth Subject: Re: Text/enriched ambiguity To: Dana S Emery Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > After all the previous discussion, perhaps its time for a > (hopefully succinct) restatement of positions, I will take the > liberty of posing the Q: Thank you much. ;-) > Why would ignorable_param_data_block be unfortunate? Because j-random-existing parser would (SHOULD!) display the ignorable_param_data_block as part of the message. > -- > dana s emery I'm sorry I didn't put in this $0.02 before text/enriched got out in the first place. :-( That's how it goes, I guess. It should be: -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 18:37:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21426; Mon, 1 Nov 93 18:08:00 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21422; Mon, 1 Nov 93 18:07:57 EST Received: from azalea.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Tue, 2 Nov 93 09:07:37 +1000 Date: Tue, 2 Nov 93 09:07:32 EST From: rhys@cs.uq.oz.au Message-Id: <9311012307.AA08165@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity >This discussion seems to have reaffirmed the utility of (or >something like it), but we still haven't resolved the issue of syntax >inside a ... block. Should a simple text/enriched >process read blindly until the , or should it parse for >text/enriched structures, check for nesting, etc.? Alas, I think there >are good arguments both ways.... Hmmm ... we can have it both ways I think: (a) The contents of the block follow text/enriched conventions. i.e. '<' becomes '<<', commands have the usual syntax, etc. (b) There are no requirements on balancing commands: the block extends until the next . Thus, we can have ... or ... or any number of other different structures. If some twisted individual puts into the text it is interpreted as a parameter block containing . We could make some recommendation that the first element of a parameter block must be a command which indicates what kind of parameter block it is, so that implementations that understand parameter blocks can skip those blocks that aren't for them. I don't think this would screw up parsers too much: the lexical analyser still pulls text/enriched tokens out in the normal way, so it isn't like or which required special handling at the lowest lexical levels. The default handling is to just toss away tokens until is encountered. Comments? Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 19:07:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21540; Mon, 1 Nov 93 18:12:07 EST Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21533; Mon, 1 Nov 93 18:12:06 EST Received: from holmes.parc.xerox.com ([13.1.100.162]) by alpha.xerox.com with SMTP id <11757(2)>; Mon, 1 Nov 1993 15:11:51 PST Received: by holmes.parc.xerox.com id <16134>; Mon, 1 Nov 1993 15:11:48 -0800 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.holmes.parc.xerox.com.sun4.41 via MS.5.6.holmes.parc.xerox.com.sun4_41; Mon, 1 Nov 1993 15:11:34 -0800 (PST) Message-Id: <4gpNSa8B0KGW82rNRd@holmes.parc.xerox.com> Date: Mon, 1 Nov 1993 15:11:34 PST Sender: Bill Janssen From: Bill Janssen To: John Gardiner Myers Subject: Re: Query on a nit: Application vs. Text conten-type Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: References: <9310291627.AA02356@www3.cern.ch> Excerpts from ext.ietf-822: 29-Oct-93 Re: Query on a nit: Applica.. John Gardiner Myers@cmu. (474) > The important distinction between the application and text primary > types is whether or not it is appropriate to show the user the "raw" > version of the data if the type is not recognized. Wording to this > effect is in section 4, paragraph 4 and appendix A requirement 4 of > RFC 1521. > It would seem to me that HTML really does belong under the "text" > top-level content type. This, of course, is where the rubber meets the road. Having looked at much HTML source, I claim it would frighten and confuse naive users with naive mail tools, and therefore should *not* be a subtype of text. Putting things like this (and the old richtext) under type `text' is exactly what breaks down the top-level type boundaries. But that's OK: I don't believe the top-level type `text' is in fact a useful thing. Bill From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 19:37:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21908; Mon, 1 Nov 93 19:06:32 EST Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21904; Mon, 1 Nov 93 19:06:30 EST Received: from mumrik.nada.kth.se by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA08158; Tue, 2 Nov 93 01:06:10 +0100 Message-Id: <9311020006.AA08158@nada.kth.se> To: John C Klensin Cc: ietf-822@dimacs.rutgers.edu Subject: Re: MIME content type reviews In-Reply-To: Your message of "Sat, 30 Oct 1993 17:00:10 -0400." <752014810.132783.KLENSIN@INFOODS.UNU.EDU> Date: Tue, 02 Nov 1993 01:06:09 +0100 From: Patrik Faltstrom Very late versions of my proposal for how to send Macintosh files with MIME is now up on ds.internic.net in the "incoming/current-ietf-docs" (or whatever the name of the directory was :-) It is only editorial changes since the versions that was submitted as internet drafts EXCEPT for the point where I state what characters is exeptet in the NAME parameter. I changed the formulations to something like "...must be a "value" according to RFC-1522...". paf From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 20:37:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22157; Mon, 1 Nov 93 20:33:39 EST Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22151; Mon, 1 Nov 93 20:33:37 EST Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H4TBNDMSB4000VAC@INFOODS.UNU.EDU>; Mon, 1 Nov 1993 20:32:34 EST Date: Mon, 01 Nov 1993 20:32:33 -0500 (EST) From: KLENSIN@infoods.mit.edu Subject: Additional MIME type review To: ietf-822@dimacs.rutgers.edu Message-Id: <01H4TBNFQ2KK000VAC@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Reminder for those of you who are at IETF: In addition to the two scheduled content subtype review sessions, there are other efforts going on that should get careful review by the MIME community. In particular, the WG that is working on PEM and its relationship with MIME is meeting Wednesday at 1330. Since this work is critical to uses of email and MIME that require authentication and interacts strongly with other uses of MIME, I'd strongly encourage people to follow and participate in the decisions being made there. --john From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 21:37:57 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26209; Mon, 1 Nov 93 21:28:33 EST Received: from PO3.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA26205; Mon, 1 Nov 93 21:28:32 EST Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id VAA15653; Mon, 1 Nov 1993 21:28:27 -0500 Received: via switchmail; Mon, 1 Nov 1993 21:28:26 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 1 Nov 1993 21:28:06 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Mon, 1 Nov 1993 21:28:04 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Mon, 1 Nov 1993 21:28:04 -0500 (EST) Message-Id: <4gpQKo200WBw06cD4B@andrew.cmu.edu> Date: Mon, 1 Nov 1993 21:28:04 -0500 (EST) From: John Gardiner Myers To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity In-Reply-To: <9311012307.AA08165@client> References: <9311012307.AA08165@client> Beak: Is didn't need any special handling at the lowest lexical levels. In fact is just renamed. It is important for parsers to be able to ignore the stuff inside of without switching lexical modes, so the text inside of should have the same rules as outside of . Even though the text/enriched commands exist inside of , it is not necessary to actually use them. One could do the colortable example much more simply as: colortable colorentry red 255 0 0 colorentry blue 0 0 255 -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-822@dimacs.rutgers.edu Mon Nov 1 20:07:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21974; Mon, 1 Nov 93 19:43:40 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21970; Mon, 1 Nov 93 19:43:37 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Tue, 2 Nov 93 10:42:51 +1000 Date: Tue, 2 Nov 93 10:42:51 EST From: rhys@cs.uq.oz.au Message-Id: <9311020042.AA04899@client> To: troth@rice.edu Subject: Re: Text/enriched ambiguity Cc: ietf-822@dimacs.rutgers.edu Rick Troth writes: > Because j-random-existing parser would (SHOULD!) >display the ignorable_param_data_block as part of the message. There are very few existing text/enriched parsers, so this isn't a problem, and since is not used by any generator at the moment as far as I know, we have a chance fix them all before someone does need . If you thinking of feeding text/enriched into older text/richtext parsers, then that won't work anyway because text/richtext parsers don't understand the '<<' sequence, so this isn't a problem. There's nothing intrisically wrong with as an idea except that it is a special case of command parsing that WILL break existing parsers, much more than usage, as discussed in my previous message, would. also gives the flexibility of having multiple nestings inside a parameter block if that every becomes necessary. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 00:41:50 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27573; Tue, 2 Nov 93 00:37:41 EST Received: from Delphi.CS.UCLA.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27569; Tue, 2 Nov 93 00:37:39 EST Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA02948; Mon, 1 Nov 93 21:37:36 -0800 Received: by twinsun.com (4.1/SMI-4.1) id AA28121; Mon, 1 Nov 93 21:10:35 PST Received: from ford.airco.co.jp by air.airco.co.jp (4.1/6.4J.6) id AA01107; Tue, 2 Nov 93 13:32:45 JST Received: from ford (localhost) by ford.airco.co.jp (4.1/6.4J.6) id AA12691; Tue, 2 Nov 93 13:21:38 JST Return-Path: Message-Id: <9311020421.AA12691@ford.airco.co.jp> Date: Tue, 2 Nov 1993 13:21:37 +0900 (JST) From: Mark Keasling Reply-To: Mark A Keasling Subject: Re: Text/enriched ambiguity To: Nathaniel Borenstein Cc: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 1 Nov 1993 09:16:55 -0500 (EST), Nathaniel Borenstein wrote... > This discussion seems to have reaffirmed the utility of (or > something like it), but we still haven't resolved the issue of syntax > inside a ... block. Should a simple text/enriched > process read blindly until the , or should it parse for > text/enriched structures, check for nesting, etc.? Alas, I think there > are good arguments both ways.... > It is my opinion, though I'm not an authority on such matters, that the simple approach would be that a parser should not attempt to parse the contents of a ... command section. Since the simple parser doesn't understand the contents of the section anyway, what does it gain by pretending that it does? If the section is NOT parsed, simple parsers won't be affected when a grammar for the section is finally decided upon. If the section IS parsed, what is the parser supposed to do when it thinks it has found an error? Should it complain about the incorrect structure of commands it doesn't understand in the first place. My $0.015. -- Mark Keasling AIR Company LTD, Nishikawa Mitsui Bldg, 1-3-14 Kitahama, Chuo-ku, Osaka 541 email: makr%air@unify.com phone: +1 81 6201 4307 fax: +1 81 6201 2107 From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 01:07:58 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27585; Tue, 2 Nov 93 00:45:17 EST Received: from inet-gw-2.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27581; Tue, 2 Nov 93 00:45:16 EST Received: by inet-gw-2.pa.dec.com; id AA02715; Mon, 1 Nov 93 21:45:12 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA28683 for pem-dev@tis.com; Tue, 2 Nov 93 00:45:07 -0500 Message-Id: <9311020545.AA28683@skidrow.lkg.dec.com> Reply-To: beast@world.std.com To: ietf-822@dimacs.rutgers.edu, Privacy Encrusted Mail Deveopment Subject: My $0.02 re MIME / secure mail In-Reply-To: Your message of "Mon, 01 Nov 93 20:32:33 EST." <01H4TBNFQ2KK000VAC@INFOODS.UNU.EDU> Date: Tue, 02 Nov 93 00:45:07 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp I see two problems of incompletness with the current PEM/MIME proposals: (1) They are obviously incomplete since they only provide for PEM secured messages and not for PGP secured messages. The format should be general enough that one could send out a message with a PEM signature and a PGP signature (and a DSS signature...) and be able to handle the more ugly and hopefully less common case where you need more than one cyphertext version due to different algorithms, etc. (2) Soon, people are going to notice that when they reply to a message and want to include an extract, they would like to have the extract authenticated. The only way I can see to do this is to include all of the message responded to, with its signature/certificates, and provide a MIME body part that is in effect a window into this message. (Most commonly to text but you might as well have a way to window into sound or an image, etc.) This also has the nice effect that a reader could be provided with a way to see all of the original message being replied to to see that the extract was/was-not out of context. You don't really want this "extract window" thing to be a multi-part with the thing windowed into as the 2nd part or something (at least I don't think so) as it is very common to have multiple windows into the same base message. You want it identified by id and have it been somewhere else with presentation to the reader normally surpressed. Donald From: KLENSIN@infoods.mit.edu To: ietf-822@dimacs.rutgers.edu >Reminder for those of you who are at IETF: In addition to the two >scheduled content subtype review sessions, there are other efforts going >on that should get careful review by the MIME community. > >In particular, the WG that is working on PEM and its relationship with >MIME is meeting Wednesday at 1330. Since this work is critical to uses of >email and MIME that require authentication and interacts strongly with >other uses of MIME, I'd strongly encourage people to follow and >participate in the decisions being made there. > > --john From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 07:38:01 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00222; Tue, 2 Nov 93 07:35:38 EST Received: from punch.ic.ac.uk by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00218; Tue, 2 Nov 93 07:35:36 EST Received: from sg1.cc.ic.ac.uk by punch.ic.ac.uk with SMTP (PP) id <15994-0@punch.ic.ac.uk>; Tue, 2 Nov 1993 12:32:56 +0000 Received: by cscmgb.cc.ic.ac.uk (920330.SGI/4.0) id AA07906; Tue, 2 Nov 93 12:34:29 GMT From: p.churchyard@ic.ac.uk Message-Id: <9311021234.AA07906@cscmgb.cc.ic.ac.uk> Subject: Re: PEM-MIME drafts To: beast@world.std.com Date: Tue, 2 Nov 93 12:34:29 gmt Cc: ietf-822@dimacs.rutgers.edu, pem-dev@tis.com In-Reply-To: <9311020545.AA28683@skidrow.lkg.dec.com>; from "Beast" at Nov 2, 93 12:45 am Although I like some of the current PEM-MIME (MIME-PEM) draft I think it has a number of problems. The main one is that there are alot of MIME implementations out there now and from what I have seen adding a multipart/headerset type is going to mean alot of code changes. Having the PEM stuff wrapped in an application/pem part does not need changes. The main problem with the current PEM standard is that there is no mechanism to allow some headers to be put into and then extracted from the enhanced text. If we allowed a PEM content-domain for RFC822-Message with specifies that there are some 822 header lines at the start of the enhanced text then the alternative proposal of content domain MIME is covered already. The meaning of header lines such as From and To in an enhanced header are not defined since they will have been excluded from the normal re-writing that takes place. But Mime related headers can be used. Peter Churchyard. From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 10:08:03 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01470; Tue, 2 Nov 93 09:52:07 EST Received: from relay2.UU.NET by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01466; Tue, 2 Nov 93 09:52:06 EST From: beyond!eng!tcrowley@uunet.uu.net Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00622; Tue, 2 Nov 93 09:52:03 -0500 Received: from beyond.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 095050.21149; Tue, 2 Nov 1993 09:50:50 EST Received: by beyond.UUCP Tue, 02 Nov 93 09:52:18 EDT Message-Id: <5A97D52C01842879@beyond.UUCP> Date: Tue, 02 Nov 93 09:52:18 EDT To: , Mark Keasling Subject: Re: Text/enriched ambiguity X-Mailer: UGate [Ver. 1.65] >> It is my opinion, though I'm not an authority on such matters, that the simple >> approach would be that a parser should not attempt to parse the contents of a >> ... command section. Since the simple parser doesn't understand >> the contents of the section anyway, what does it gain by pretending >> that it does? You have to parse the contents, because you need to be able to recognize the end of the block. Parse is actually too strong a word - its really just lexical analysis. looks like it meets the needs. However, this whole discussion is probably not too important. The basic usefulness of enriched, if it ever gets nailed down, is in being a simple, clear standard for passing a bit of marked-up text. It's value is in being a lingua franca, not in having lots of whiz-bang capabilities. My bet, given my experience with a couple of systems that provide more powerful editing systems, is text/enriched will simply be an mp/alternative format that provides a little more value than plain text. In fact, given the wider use of windowed systems and the resultant variety in linewidths, its linewrapping semantics may be more useful in heterogeneous exchange than anything else. Production systems will continue to use private or de-facto standard protocols for sending more complete information. There's no way text/enriched can ever be complete enough to handle that. Technically its possible, but politically it will never happen. Terry From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 10:38:03 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01744; Tue, 2 Nov 93 10:11:46 EST Received: from domen.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01740; Tue, 2 Nov 93 10:11:44 EST Message-Id: <9311021511.AA01740@dimacs.rutgers.edu> Received: from localhost by domen.uninett.no with SMTP (PP) id <19196-0@domen.uninett.no>; Tue, 2 Nov 1993 16:11:37 +0100 To: Rick Troth Cc: ietf-822@dimacs.rutgers.edu Subject: Re: file transfer in particular In-Reply-To: Your message of "Mon, 01 Nov 1993 01:18:43 CST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Nov 1993 16:11:36 +0100 From: "Harald T. Alvestrand" This application you describe should be a multipart, no question of that. The thing yoiu are doing, adding undocumented and nonstandard arguments to a content-type, CANNOT be right. Harald T. Alvestrand From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 11:08:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02350; Tue, 2 Nov 93 11:01:48 EST Received: from uswat.advtech.uswest.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02345; Tue, 2 Nov 93 11:01:42 EST Received: from futureworld.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA17897 (5.65c/IDA-1.4.4 for ); Tue, 2 Nov 1993 09:01:01 -0700 Received: from localhost.uswest.com by futureworld.advtech.uswest.com (advtech.uswest.com) id AA20777 (4.1/at-generic.16Sep93); Tue, 2 Nov 93 09:00:31 MST Message-Id: <9311021600.AA20777@futureworld.advtech.uswest.com> To: p.churchyard@ic.ac.uk Cc: beast@world.std.com, ietf-822@dimacs.rutgers.edu, pem-dev@tis.com Subject: Re: PEM-MIME drafts In-Reply-To: Your message of "Tue, 02 Nov 1993 12:34:29 GMT." <9311021234.AA07906@cscmgb.cc.ic.ac.uk> Date: Tue, 02 Nov 1993 09:00:31 -0700 From: Brad Huntting > the meaning of header lines such as From and To in an enhanced header > are not defined since they will have been excluded from the normal > re-writing that takes place. But Mime related headers can be used. Signing ANY headers is a Bad Idea (tm). All headers are considered fair game by most MTA's. It's common to take any header and change the line wrap for no reason. Similarly, there's rampent case changes especially in strings like "Message-ID" to "Message-Id", "CC:" to "Cc:". The list is endless. If you want to sign headers, you'd best put them in the body of the message. braD From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 12:00:03 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01944; Tue, 2 Nov 93 10:34:29 EST Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01940; Tue, 2 Nov 93 10:34:27 EST Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4TXIP8UWG9BVEL0@INNOSOFT.COM>; Tue, 2 Nov 1993 07:34:14 PST Date: Tue, 02 Nov 1993 07:23:56 -0800 (PST) From: Ned Freed Subject: Re: My $0.02 re MIME / secure mail In-Reply-To: Your message dated "Tue, 02 Nov 1993 00:45:07 -0500" <9311020545.AA28683@skidrow.lkg.dec.com> To: "Beast (Donald E. Eastlake, 3rd)" Cc: ietf-822@dimacs.rutgers.edu, Privacy Encrusted Mail Deveopment Message-Id: <01H4TYRSILI69BVEL0@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > (1) They are obviously incomplete since they only provide for PEM > secured messages and not for PGP secured messages. The format should > be general enough that one could send out a message with a PEM > signature and a PGP signature (and a DSS signature...) and be able to > handle the more ugly and hopefully less common case where you need > more than one cyphertext version due to different algorithms, etc. The incompleteness of the specification in this regard is intentional. It is not our purpose to specify how PGP would fit into MIME hee. However, your implicit assumption here seems to be that the structure is not general enough to handle PGP. This is in fact untrue. As a matter of fact, it should be possible to have a PEM and a PGP signature on the same document without duplicating any content. (The encryption case requires repeated content for obvious reasons.) Work is now underway to clarify how these things are done. While this work will probably stop short of specifying the handling of PGP, it sould make it possible to address this issue with a relatively simple additional specification. (This presupposes that PGP will elect to use this approach to MIME encapsulation, which may not be the way the PGP community decides to do it.) > (2) Soon, people are going to notice that when they reply to a message > and want to include an extract, they would like to have the extract > authenticated. The only way I can see to do this is to include all of > the message responded to, with its signature/certificates, and provide > a MIME body part that is in effect a window into this message. (Most > commonly to text but you might as well have a way to window into sound > or an image, etc.) This also has the nice effect that a reader could > be provided with a way to see all of the original message being > replied to to see that the extract was/was-not out of context. You > don't really want this "extract window" thing to be a multi-part with > the thing windowed into as the 2nd part or something (at least I don't > think so) as it is very common to have multiple windows into the same > base message. You want it identified by id and have it been somewhere > else with presentation to the reader normally surpressed. Well, it isn't quite this one-sided. MIME-PEM supports selective enhancement of parts of a message. The price you pay for this, however, is the loss of overall message integrity. The original sender could secure each section of the message separately as well as secure the message as a whole, but the overhead involved would be pretty big. The pointer scheme you propose is another reasonable approach. Please note that work is also underway to specify how internal references inside a message will work. Once this is done it should be a relatively trivial matter to define some very simple type of document that uses pointers to secured parts to build up a composite response. Ned From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 11:38:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02010; Tue, 2 Nov 93 10:42:48 EST Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02006; Tue, 2 Nov 93 10:42:46 EST Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4TXIP8UWG9BVEL0@INNOSOFT.COM>; Tue, 2 Nov 1993 07:42:15 PST Date: Tue, 02 Nov 1993 07:34:33 -0800 (PST) From: Ned Freed Subject: RE: PEM-MIME drafts In-Reply-To: Your message dated "Tue, 02 Nov 1993 12:34:29 +0000 (gmt)" <9311021234.AA07906@cscmgb.cc.ic.ac.uk> To: p.churchyard@ic.ac.uk Cc: beast@world.std.com, ietf-822@dimacs.rutgers.edu, pem-dev@tis.com Message-Id: <01H4TZ1QGN2G9BVEL0@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > Although I like some of the current PEM-MIME (MIME-PEM) draft > I think it has a number of problems. The main one is that there are > alot of MIME implementations out there now and from what I have seen > adding a multipart/headerset type is going to mean alot of code changes. As you probably know, I agree with you insofar as the current header-set mechanism goes. However, this is a separate issue from MIME-PEM and is in the process of being dealt with in the header-set proposal itself. Once we have a way to deal with header-set parameterization I believe most of the more serious implementation problems go away. > Having the PEM stuff wrapped in an application/pem part does not need > changes. I agree that fewer changes are needed. However, the larger question is whether we should go for the cheap fix and the limitations it imposes or try to do this right the first time. The issue of PGP integration is a good case in point. The MIME-PEM proposal makes dual signatures pretty easy. > The main problem with the current PEM standard is that there is no mechanism > to allow some headers to be put into and then extracted from the enhanced > text. If we allowed a PEM content-domain for RFC822-Message with specifies > that there are some 822 header lines at the start of the enhanced text > then the alternative proposal of content domain MIME is covered already. This is precisely what Jeff Schiller's proposal does now. By changing the semantics of the inner object from plain text to a MIME object, you can have all the headers you want in there, with whatever semantics you like. > The meaning of header lines such as From and To in an enhanced header > are not defined since they will have been excluded from the normal re-writing > that takes place. But Mime related headers can be used. Actually, you can have From: and To: in there as well in either encapsulation scheme, since both allow for nested messages. The lack of rewriting is the price you pay for protecting them with a signature. Ned From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 12:08:04 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01767; Tue, 2 Nov 93 10:17:36 EST Received: from domen.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01763; Tue, 2 Nov 93 10:17:32 EST Message-Id: <9311021517.AA01763@dimacs.rutgers.edu> Received: from localhost by domen.uninett.no with SMTP (PP) id <19256-0@domen.uninett.no>; Tue, 2 Nov 1993 16:17:28 +0100 To: ietf-822@dimacs.rutgers.edu Subject: A spec for showing language in MIME headers Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Tue, 02 Nov 1993 16:17:26 +0100 From: "Harald T. Alvestrand" ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Hello, I have written up a draft of a draft, showing what I feel that a "Content-language" header should look like. In the process, I also found a need to augument multipart/alternative with an argument that told people what the difference is; I found this easier than starting to define multipart/alternative(format), multipart/alternative-language, multipart/alternative-rating (rating=pg/r/x, for MIME video rental :-) and so on. It's too late to give it much thought at the current IETF, but final authority is in the lists anywaon. Ready, set - COMMENT! Regards, Harald T. Alvestrand ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Internet-Draft Language tag for MIME body parts This document describes a Content-Language: header for use with body parts of MIME. It also describes a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header. The syntax of this header is: Content-language: <2xAlpha>[_2xAlpha] (comment) [ , ... ] The first 2xAlpha is an ISO 639 code for a language. If required, the second 2xAlpha may define the country using a particular language (such as en_GB and en_US), as per ISO 639. If further information is needed, it is carried as RFC-822 comments until ISO 639 is revised. For languages that do not have an ISO 639 code, the language "xx" is used, with an appropriate geographical area and comment. This is not very useful for picking the correct thing, but is better than lying. (The codes xa to xz are reserved for local use in ISO 639 ) This may include: - Dialect information. ISO 639 does not recognize variants of a language that do not correspond to countries. - Languages not listed in ISO 639. If multiple languages are used in the MIME body part, they are listed with commas between them. If the comments need the usage of extended character sets, RFC 1342 is used inside the comment. MEANING The meaning of the header is: - For a single information object, it should be taken as the set of languages that is required for a complete comprehension of the complete object. Examples: Simple text. - For an aggregation of information object, it should be taken as the set of languages used inside components of that aggregation. Examples: Document stores and libraries. - For information objects whose purpose in life is providing alternatives, it should be regarded as a hint that the material inside is provided in several languages, and that one has to inspect each of the alternatives in order to find its language or languages. In this case, multiple languages need not mean that one needs to be multilingual to get complete understanding of the document. Examples: MIME multipart/alternative. EXAMPLES: Norwegian official document, with parallel text in both official versions of Norwegian. Both versions are readable by all Norwegians. Content-language: no (nynorsk), no (bokm=86l) Voice recording from the London docks Content-language: en_GB (cockney) Document in Sami, which does not have an ISO 639 code, and is spoken in several countries, but with about half the speakers in Norway Content-language: xx_no (Sami) An English-French dictionary Content-language: en, fr (This is a dictionary) An official EC document Content-language: en, fr, ge, da, gr, it USAGE EXAMPLES Examples of protocol usage of this header are: - WWW selection of an appropriate version of information for display, based on a profile for the user listing languages that are understood - MIME usage of alternate body parts in E-mail THE DIFFERENCE=3D PARAMETER Currently, Multipart/Alternative only has one parameter: boundary. The common usage of Multipart/Alternative is to have more than one format of the same message (f.ex. PostScript and ASCII). The use of language tags to differentiate between different alternatives will certainly not lead all MIME UAs to present the most sensible body part as default. Therefore, a new parameter is defined, to allow the configuration of MIME readers to handle language differences in a sensible manner. Name: Difference Value: One of content-type content-language Further values can be registered with IANA; it must be the name of a header for which a definition exists in a published document. If not present, Difference=3DContent-type is assumed. The intent is that the MIME reader can look at this header of the message component to do an intelligent choice of what to present to the user. MIME EXAMPLE: Content-type: multipart/alternative; difference=3Dcontent-language Content-language: en, fr --limit Content-language: fr --limit Content-language: en --limit-- In order to give a sensible display first on non-MIME readers, the English version should usually be the first one in the list of body parts. SECURITY CONSIDERATIONS Security considerations are not considered in this memo CHARACTER SET CONSIDERATIONS See RFC 1342 comment. Codes are always US-ASCII. GATEWAYING CONSIDERATIONS RFC 1327 defines a Language: header. This header is not recommended now, because it is defined to be a single 2-letter language code, and the X.400 header it is supposed to gateway is a list of language codes. It is suggested that RFC 1327 be updated to produce the Content-language: header, and to turn this header into the ISO/CCITT specified Language components rather than the RFC-822-headers heading extension. REFERENCES ISO 639 RFC 1341 RFC 1342 RFC 1327 ------- =_aaaaaaaaaa0-- From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 15:08:36 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08556; Tue, 2 Nov 93 14:41:14 EST Received: from gw1.att.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA08552; Tue, 2 Nov 93 14:41:12 EST Message-Id: <9311021941.AA08552@dimacs.rutgers.edu> From: hansen@pegasus.att.com (t.l.hansen) To: ietf-822@dimacs.rutgers.edu Date: 2 Nov 1993 14:36 EST Subject: Re: Text/enriched ambiguity References: < This discussion seems to have reaffirmed the utility of (or < something like it), but we still haven't resolved the issue of syntax < inside a ... block. Should a simple text/enriched < process read blindly until the , or should it parse for < text/enriched structures, check for nesting, etc.? Alas, I think there < are good arguments both ways.... < This discussion seems to have reaffirmed the utility of (or < something like it), but we still haven't resolved the issue of syntax < inside a ... block. Should a simple text/enriched < process read blindly until the , or should it parse for < text/enriched structures, check for nesting, etc.? Alas, I think there < are good arguments both ways.... The latter. In other words, don't change the way it is currently spec'd out. Doing it the other way leads to the same mess that had. (Even if it was only 20 lines of code. :-) ) Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 16:38:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09759; Tue, 2 Nov 93 16:15:38 EST Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09755; Tue, 2 Nov 93 16:15:33 EST Received: from [198.170.222.205] (latma.ietf28.sesqui.net) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA04559; Tue, 2 Nov 1993 16:15:10 -0500 Date: Tue, 2 Nov 1993 16:15:10 -0500 Message-Id: <199311022115.AA04559@ivory.educom.edu> X-Sender: conklin@educom.edu (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-822@dimacs.rutgers.edu From: conklin@ivory.educom.edu (Jim Conklin) Subject: Re: Text/enriched ambiguity >In other words, I think that, inevitably, text/enriched is neither >powerful enough to do everything nor simple enough to satisfy everyone, >but that if we were to change it from its current spec, we'd be better >off simplifying even further at the expense of power. Here, here! I couldn't agree more, Nathaniel! Jim From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 18:08:07 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11108; Tue, 2 Nov 93 18:03:24 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11104; Tue, 2 Nov 93 18:03:17 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 3 Nov 93 07:58:37 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311022258.AA04606@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headersd To: Harald.T.Alvestrand@uninett.no (Harald T. Alvestrand) Date: Wed, 3 Nov 93 7:58:36 JST Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311021517.AA01763@dimacs.rutgers.edu>; from "Harald T. Alvestrand" at Nov 2, 93 4:17 pm X-Mailer: ELM [version 2.3 PL11] > The syntax of this header is: > > > > Content-language: <2xAlpha>[_2xAlpha] (comment) [ , ... ] > > > > The first 2xAlpha is an ISO 639 code for a language. If required, the > > second 2xAlpha may define the country using a particular language > > (such as en_GB and en_US), as per ISO 639. I have heard that there are about 4,000 to 8,000 languages (neglecting dialects) in the world. If so, I think your scheme is no good. Masataka Ohta From owner-ietf-822@dimacs.rutgers.edu Tue Nov 2 22:38:09 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15664; Tue, 2 Nov 93 22:21:21 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15660; Tue, 2 Nov 93 22:21:15 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Wed, 3 Nov 93 13:21:10 +1000 Date: Wed, 3 Nov 93 13:21:09 EST From: rhys@cs.uq.oz.au Message-Id: <9311030321.AA00584@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headersd Harald T. Alvestrand writes: >> The syntax of this header is: >> >> Content-language: <2xAlpha>[_2xAlpha] (comment) [ , ... ] I would prefer '-' rather than '_', mainly because I see future possibilities for using these language tags in text/enriched to get around some of the unification headaches of ISO-10646 (no, I'm not suggesting we do it now), and '-' fits in nicer with the command syntax of text/enriched. Masataka Ohta writes: >I have heard that there are about 4,000 to 8,000 languages (neglecting >dialects) in the world. > >If so, I think your scheme is no good. I wouldn't go that far. The 2-letter codes he is using are in the various ISO standards for such tags, so it is a good start, building on previous efforts. It also lets ISO worry about wrangling with future names, and takes the burden off the IETF's shoulders. I suggest though that the tags not be limited to 2 letters. Put in some weasel words to the effect that initially the first tag may have any of the 2-letter codes set out in ISO 639, and that it is expected that a future update to ISO 639 will define additional tags which will also be valid tags for Content-Language purposes. The country code isn't a problem IMHO since those codes change very infrequently, but removing the 2-letter limitation "just in case" can't hurt. Overall, I like this proposal: there's just a few sharp edges to file off. :-) Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Wed Nov 3 02:38:11 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17004; Wed, 3 Nov 93 02:37:12 EST Received: from world.std.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17000; Wed, 3 Nov 93 02:37:11 EST Received: from localhost by world.std.com (5.65c/Spike-2.0) id AA06941; Wed, 3 Nov 1993 02:37:06 -0500 Message-Id: <199311030737.AA06941@world.std.com> To: Dave Crocker Cc: "Beast (Donald E. Eastlake 3rd)" , Internet Message Extensions Subject: Re: comment on draft-vandreuil-mime-sig-00.txt In-Reply-To: Your message of "Mon, 01 Nov 1993 12:03:39 PST." <9311012003.AA15365@Mordor.Stanford.EDU> Date: Wed, 03 Nov 1993 02:37:05 -0500 From: "Beast (Donald E. Eastlake 3rd)" Dave, I like PCI more than the vandreuil signature proposal. However, I would prefer for the lines to really be 822 lines rather than this funnyness qwith ";" and having multiple x:'s on a line. I also don't really like the "nest" format. I think the fewer mechanisms there are, the better. Possibly multiple locals should be handled by a multipart type... Donald From: Dave Crocker To: "Beast (Donald E. Eastlake 3rd)" Cc: Internet Message Extensions Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 01 Nov 93 02:48:07 -0500. <19931101 0748.AA19894@world.std.com> }Donald, } }I'd be interested in your views on PCI, as a mechanism for subsuming the }signature function. } }d/ From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 00:39:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02883; Thu, 4 Nov 93 00:26:14 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02879; Thu, 4 Nov 93 00:26:12 EST Received: by brazos.is.rice.edu (AA17153); Wed, 3 Nov 93 23:26:11 CST Date: Wed, 3 Nov 1993 23:23:39 -0600 (CST) From: Rick Troth Subject: Re: comment on draft-vandreuil-mime-sig-00.txt To: ietf-822@dimacs.rutgers.edu In-Reply-To: <199311030737.AA06941@world.std.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greg, What about changing the multi-line delimiter from '/' to ';'. There does seem to be precedent for using semi-colon to delimit "lines" and it should be less likely to show-up as part of the actual text of, say, and earth address than slash. -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 01:09:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02933; Thu, 4 Nov 93 00:35:28 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02929; Thu, 4 Nov 93 00:35:26 EST Received: by brazos.is.rice.edu (AA17246); Wed, 3 Nov 93 23:34:56 CST Date: Wed, 3 Nov 1993 23:26:45 -0600 (CST) From: Rick Troth Subject: Re: Text/enriched ambiguity To: rhys@cs.uq.oz.au Cc: ietf-822@dimacs.rutgers.edu, troth@rice.edu In-Reply-To: <9311020042.AA04899@client> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There are very few existing text/enriched parsers, so this isn't a problem, > and since is not used by any generator at the moment as far as I > know, we have a chance fix them all before someone does need . But some of us are using a "simple SGML" parser for richtext and will use mostly the same code for enriched. But ... > If you thinking of feeding text/enriched into older text/richtext parsers, > then that won't work anyway because text/richtext parsers don't understand > the '<<' sequence, so this isn't a problem. You're telling me that it's not a "drop in". Fine. > There's nothing intrisically wrong with as an idea except that it > is a special case of command parsing that WILL break existing parsers, much > more than usage, as discussed in my previous message, would. You just said "There are very few existing text/enriched parsers", so why is this a problem? I understand and appreciate the capability of auto-balancing but place a greater value on: message context --- outside the angle brackets operators (commands) --- inside the angle brackets Now I'm a newbe to SGML, well ... I've been watching it for several years, but only recently started coding for it, so I may be all wet with this goal. John? You seem to know it pretty well. > > also gives the flexibility of having multiple nestings inside a parameter > block if that every becomes necessary. Now this is an excellent point with which I can't argue. For me the question is: is nested a real possibility? I'm all for maximum open-endedness. > Cheers, > > Rhys. -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 02:09:24 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02933; Thu, 4 Nov 93 00:35:28 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02929; Thu, 4 Nov 93 00:35:26 EST Received: by brazos.is.rice.edu (AA17246); Wed, 3 Nov 93 23:34:56 CST Date: Wed, 3 Nov 1993 23:26:45 -0600 (CST) From: Rick Troth Subject: Re: Text/enriched ambiguity To: rhys@cs.uq.oz.au Cc: ietf-822@dimacs.rutgers.edu, troth@rice.edu In-Reply-To: <9311020042.AA04899@client> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02933; Thu, 4 Nov 93 00:35:28 EST Received: from brazos.is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02929; Thu, 4 Nov 93 00:35:26 EST Received: by brazos.is.rice.edu (AA17246); Wed, 3 Nov 93 23:34:56 CST Date: Wed, 3 Nov 1993 23:26:45 -0600 (CST) From: Rick Troth Subject: Re: Text/enriched ambiguity To: rhys@cs.uq.oz.au Cc: ietf-822@dimacs.rutgers.edu, troth@rice.edu In-Reply-To: <9311020042.AA04899@client> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > There are very few existing text/enriched parsers, so this isn't a problem, > and since is not used by any generator at the moment as far as I > know, we have a chance fix them all before someone does need . But some of us are using a "simple SGML" parser for richtext and will use mostly the same code for enriched. But ... > If you thinking of feeding text/enriched into older text/richtext parsers, > then that won't work anyway because text/richtext parsers don't understand > the '<<' sequence, so this isn't a problem. You're telling me that it's not a "drop in". Fine. > There's nothing intrisically wrong with as an idea except that it > is a special case of command parsing that WILL break existing parsers, much > more than usage, as discussed in my previous message, would. You just said "There are very few existing text/enriched parsers", so why is this a problem? I understand and appreciate the capability of auto-balancing but place a greater value on: message context --- outside the angle brackets operators (commands) --- inside the angle brackets Now I'm a newbe to SGML, well ... I've been watching it for several years, but only recently started coding for it, so I may be all wet with this goal. John? You seem to know it pretty well. > > also gives the flexibility of having multiple nestings inside a parameter > block if that every becomes necessary. Now this is an excellent point with which I can't argue. For me the question is: is nested a real possibility? I'm all for maximum open-endedness. > Cheers, > > Rhys. -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 04:05:59 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04534; Thu, 4 Nov 93 03:45:16 EST Received: from inet-gw-2.pa.dec.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04530; Thu, 4 Nov 93 03:45:15 EST Received: by inet-gw-2.pa.dec.com; id AA22525; Thu, 4 Nov 93 00:45:07 -0800 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA17208 for ietf-822@dimacs.rutgers.edu; Thu, 4 Nov 93 03:45:02 -0500 Message-Id: <9311040845.AA17208@skidrow.lkg.dec.com> To: Rick Troth Cc: ietf-822@dimacs.rutgers.edu Subject: Re: comment on draft-vandreuil-mime-sig-00.txt In-Reply-To: Your message of "Wed, 03 Nov 93 23:23:39 CST." Date: Thu, 04 Nov 93 03:45:02 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp It is also common for "/" to occur in Mail Stops. Mine at DEC is LKG2-1/BB3. Donald From: Rick Troth To: ietf-822@dimacs.rutgers.edu In-Reply-To: <199311030737.AA06941@world.std.com> >Greg, > > What about changing the multi-line delimiter from '/' >to ';'. There does seem to be precedent for using semi-colon >to delimit "lines" and it should be less likely to show-up as >part of the actual text of, say, and earth address than slash. > >-- >Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 04:35:59 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04663; Thu, 4 Nov 93 04:09:13 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04659; Thu, 4 Nov 93 04:09:10 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Thu, 4 Nov 93 19:09:05 +1000 Date: Thu, 4 Nov 93 19:09:04 EST From: rhys@cs.uq.oz.au Message-Id: <9311040909.AA00721@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: Text/enriched ambiguity >> There's nothing intrisically wrong with as an idea except that it >> is a special case of command parsing that WILL break existing parsers, much >> more than usage, as discussed in my previous message, would. > > You just said "There are very few existing text/enriched parsers", >so why is this a problem? Mainly because it radically alters the syntax for commands, for something that may not be useful for quite a while, if ever. So, some implementors may feel uneasy parsing command formats that have no use at the moment. The block method (skip till you get ) is somewhat cleaner in how current implementations will cope with future additions. > Now I'm a newbe to SGML, well ... I've been watching it for >several years, but only recently started coding for it, so I may be >all wet with this goal. John? You seem to know it pretty well. I'd also be interested in knowing how SGML treats "to be defined later" parameter blocks. Is it necessary to set out an entire DTD ahead of time, or can "holes" be left for arbitrary material? Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 09:40:15 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06122; Thu, 4 Nov 93 09:21:46 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06096; Thu, 4 Nov 93 09:20:03 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 4 Nov 93 23:14:48 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311041415.AA11689@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headersd To: rhys@cs.uq.oz.au Date: Thu, 4 Nov 93 23:14:47 JST Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311030321.AA00584@client>; from "rhys@cs.uq.oz.au" at Nov 3, 93 1:21 pm X-Mailer: ELM [version 2.3 PL11] > Masataka Ohta writes: > > >I have heard that there are about 4,000 to 8,000 languages (neglecting > >dialects) in the world. > > > >If so, I think your scheme is no good. > > I wouldn't go that far. The 2-letter codes he is using are in the various > ISO standards for such tags, so it is a good start, building on previous > efforts. It also lets ISO worry about wrangling with future names, and takes > the burden off the IETF's shoulders. What? If it is used in various ISO standards, it should have made ISO worry about wrangling with future names, already. So, can't we wait till a revised version comes up, unless we have urgent need for it. > I suggest though that the tags not be limited to 2 letters. Put in some > weasel words to the effect that initially the first tag may have any of > the 2-letter codes set out in ISO 639, I'm afraid it is effectively equivalent to do the ISO's job by IETF. > The country code isn't a problem IMHO since those codes change very > infrequently, The country code changes quite frequently. There is no USSR now. If we do need the code, the more stable method is to do: <639 code>---[.[.]] which is, still, not at all, complete. > but removing the 2-letter limitation "just in case" can't hurt. It is easy to remove limitations later. It is impossible to add limitations incompatible to the already registered names later. MO From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 10:06:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06517; Thu, 4 Nov 93 09:42:31 EST Received: from HAL.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06512; Thu, 4 Nov 93 09:42:30 EST Received: from floyd (floyd.hal.COM) by hal.com (4.1/SMI-4.1.1) id AA16526; Thu, 4 Nov 93 06:42:27 PST Received: by floyd (4.1/SMI-4.1.2) id AA04214; Thu, 4 Nov 93 08:42:26 CST Message-Id: <9311041442.AA04214@floyd> To: ietf-822@dimacs.rutgers.edu Subject: Priority header values From: frankb@hal.com (Frank Bieser) Date: Thu, 4 Nov 1993 08:42:25 -0600 (CST) X-Mailer: Ishmail 1.0 Sorry to interrupt the MIME discussions, but I cannot, for my life, find where the Priority: mail header is defined. I've searched through the RFC archives, and only find references to it, claiming it is defined in 822. But it is not; at least not in my copy. Could some kind soul point me to where I can find a defined range of values for this beasty? thanks, -- -- Frank Bieser (frankb@hal.com) From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 10:35:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06010; Thu, 4 Nov 93 09:10:56 EST Received: from othello.admin.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06006; Thu, 4 Nov 93 09:10:54 EST Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b) id AA02082; Thu, 4 Nov 93 15:10:51 +0100 Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0) id AA18473; Thu, 4 Nov 93 15:10:48 +0100 Date: Thu, 4 Nov 93 15:10:48 +0100 Message-Id: <9311041410.AA18473@mercutio.admin.kth.se> From: Olle Jarnefors To: ietf-822@dimacs.rutgers.edu Cc: Olle Jarnefors In-Reply-To: <9311021517.AA01763@dimacs.rutgers.edu> (Tue, 02 Nov 1993 16:17:26 +0100; From: "Harald T. Alvestrand" ) Subject: Re: A spec for showing language in MIME headers Harald T. Alvestrand writes: > I have written up a draft of a draft, showing what I feel that > a "Content-language" header should look like. Looks good as a draft of a draft. > Ready, set - COMMENT! Here are mine: > Language tag for MIME body parts > > Some text should be included here about what kinds of language information the Content-Language: field is intended for, perhaps something like this: -- By "language" in this document is meant only natural languages, like Norwegian, and artificial langauges designed to substitute natural languages, like Esperanto. E.g. so- called programming languages are not covered. -- Both languages that have a written form and languages that are only spoken can be indicated by the Content-Language: header field. (The latter case may be relevant for Audio/Basic body parts.) It can be used for both living languages and dead languages. -- Language groups, individual languages and dialects of languages can be indicated in this scheme, which doesn't in itself force the adoption of any specific position regarding e.g. if Chinese is one language or a group of related languages. > This document describes a Content-Language: header for use with body > parts of MIME. I suppose a new Content-Language: header field is preferred to a new "content-language=" parameter in the Content-Type: header, because language information may be relevant to many different content-types. As I understand it, each content-type has its own name space for parameters and a parameter to a content-type C1 with the same name as a parameter to a content-type C2 may have totally unrelated semantics. (RFC 1521 says, on one hand: ... The set of meaningful parameters differs for the different types. In particular, there are NO globally-meaningful parameters that apply to all content-types. and on the other: ... Although most parameters make sense only with certain content-types, others are "global" in the sense that they might apply to any subtype. For example, the "boundary" parameter makes sense only for the "multipart" content-type, but the "charset" parameter might make sense with several content-types. I suppose this doesn't exclude using "charset" with some other semantics than the usual in the definition of some new content-type. Perhaps we should then also have a Content-Filename-Suggestion: header for those many cases where it's appropriate to save the body of a body-part in a file? And a Header-Filename-Suggestion: for saving the header of the body-part? > It also describes a new parameter to the Multipart/Alternative type, > to aid in the usage of the Content-Language: header. Can a new parameter be added to an already defined content-type or must a new content-type name be chosen when extending it in this way? > The syntax of this header is: > > Content-language: <2xAlpha>[_2xAlpha] (comment) [ , ... ] > > The first 2xAlpha is an ISO 639 code for a language. If required, the > second 2xAlpha may define the country using a particular language > (such as en_GB and en_US), as per ISO 639. I would prefer a more general syntax definition, something like this (using RFC 822 notation): The syntax of this header is: "Content-Language:" language-token *("," language-token) where language-token = language-code ["-" variant-code] language-code = 1*8 ALPHA variant-code = 1*8 ALPHA The case of a letter in a is insignificant. Like in all structured header fields, comments as defined in RFC 822 can be inserted between s and commas. These are intended for information comprehensible for human readers, not for data to be interpreted by programs. The comments are also subject to interpretation according to RFC 1522, so that characters not available in US-ASCII can be used. At present only these parts of the name space is used: 2 ALPHA ; language code according to ISO 639 "XI" 2*6 ALPHA ; additional language code, registered with IANA "XX" 2*6 ALPHA ; language code for private or experimental use It is expected that 3 ALPHA in the future will be used for the three-letter language codes of a forthcoming second part of ISO 639. The name space is used in this way: 2 ALPHA ; country code registered according to ISO 3166 "XI" 2*6 ALPHA ; language variant code registered with IANA "XX" 2*6 ALPHA ; language variant code for private or experimental use Substantial differences from Haralds draft: + A syntax to which all future extensions of the allowed values must conform is given. + Comments are not used to provide information meant to be understood by programs. + Registration of values with IANA is introduced to compensate for the slowness of the ISO standardization process. + The second part of a is generalized from only country code to any language variant. Different dialects are a more important aspect than country for many small languages, like for the Sami language (also called Lappish), where the most distant dialects are not mutually understandable and differ more than e.g. the languages Swedish and Norwegian. Also different orthographies for the same language can be handled with this extended variant code. (Several former Soviet rupublics where the major language belongs to the Turkish language group are switching from the Cyrillic script to the Latin script.) + As separator between the two parts of a "-" is used instead of "_". This is of course a minor point, but I think that this change is justified by making IETF language codes easily distinguishable from the more limited language codes of the form "en_US" used in Posix and X/Open locale names. > If further information is needed, it is carried as RFC-822 comments > until ISO 639 is revised. RFC 822-type comments should only be used for human-readable- only information. I think this is in the spirit of RFC 822, which states: The comment construct permits message originators to add text which will be useful for human readers, but which will be ignored by the formal semantics. ... > For languages that do not have an ISO 639 code, the language "xx" is > used, with an appropriate geographical area and comment. This is not > very useful for picking the correct thing, but is better than lying. > (The codes xa to xz are reserved for local use in ISO 639 ) I doubt that ISO 639 has reserved any codes for private use. Besides this, there is definitely a potential use for more than 26 different private language codes, considering that the total number of languages is probably in excess of 6000. > This may include: > > - Dialect information. ISO 639 does not recognize variants of a > language that do not correspond to countries. Also different orthographies for the same language should be possible to indicate, as well as competing language forms that are not attributable to different geographical areas or dialects, like the Bokmal and Nynorsk forms of Norweian. > - Languages not listed in ISO 639. The current ISO draft for three-letter language codes, ISO CD 639-2, also contains codes for - groups of languages such as "gem" for Germanic (Other) - historical forms of some languages such as "enm" for English, Middle (1100-1500) and "non" for Norse, Old. The first case should be handled by a language code. In the second case, if no ISO-standardized code is available, a variant code should be used when the historical language is a historical form of a language spoken today (like Medieval Swedish), while a language code should be used when it isn't (like the original Indo-European language). > The meaning of the header is: > > - For a single information object, it should be taken as the set of > languages that is required for a complete comprehension of the > complete object. Examples: Simple text. What about a fully bilingual text? Or an English text containing a few non-translated Latin quotations? Or an English text containing one French phrase such as "tour de force"? Or a long Swedish text with a summary in English at the top? It might be better to have two different header fields: Content-Language: indicating one or more languages, each of which is in itself sufficient for full understanding of the object. Content-Supplemental-Language: indicating one or more languages that are required in addition to the Content-Langauge: language(s) for a complete comprehension of every part of the object. > Norwegian official document, with parallel text in both official > versions of Norwegian. Both versions are readable by all Norwegians. > > Content-language: no (nynorsk), no (bokm=86l) I think the second comment should be: (=?ISO-8859-1?Q?bokm=E5l?=) But in this case I would prefer Content-Language: no-xiny, no-xibok provided that "xiny" and "xibok" have been registered as language variant codes with IANA for Nynorsk and Bokmal respectively. > Voice recording from the London docks > > Content-language: en_GB (cockney) Here I would like Content-Language: en-xxcockn (cockney) especially in the case of a text object, to allow for a speech synthesis system to automatically select the right dialect module. (I use a private variant code here, because I don't expect individual dialects of many languages to be registered with IANA.) > Document in Sami, which does not have an ISO 639 code, and is spoken > in several countries, but with about half the speakers in Norway > > Content-language: xx_no (Sami) There is a code for Sami, "smi", in ISO CD 639-2 and it may be convenient to register "xismi" with IANA, waiting for 639-2 to be adopted as an IS. At the same time the very dissimilar Sami dialects should be registered as language variants. (It's inplausible that one would want to indicate a Norwegian or Swedish form of Sami, since the dialect and orthography differences are more or less perpendicular to the Swedish-- Norwegian border, following ancient seasonal migaration patterns. Both the South Sami and the North Sami dialects are used in both Norway and Sweden.) My version of this example would be: Content-Language: xismi-xis (South Sami) > An official EC document > > Content-language: en, fr, ge, da, gr, it An official EC (or is it EU, nowadays?) document must include fully equivalent texts in these languages. In this case Harald's semantic criterion -- the set of languages that is required for a complete comprehension of the complete object -- becomes problematic. If you have read and understood the Danish text you are probably not interested in also reading the same thing in English or French. You could in this case use e.g. "Content- Language: en", but that would be an arbitrary selection of one of several equivalent alternatives. I think that my weaker semantics for Content-Language: is more practical. > Content-type: multipart/alternative; difference=3Dcontent-language > Content-language: en, fr > > --limit > Content-language: fr > > --limit > Content-language: en > > --limit-- To make the example more realistic I would suggest including the first paragraph of Gustave Flaubert's novel "Madame Bovary" here (which should be free of copyright restrictions). > In order to give a sensible display first on non-MIME readers, the > English version should usually be the first one in the list of body > parts. Maybe add here: "... if the sender has no particular reason to suppose another language would be more appropriate for (the majority of) the recipient(s)." > CHARACTER SET CONSIDERATIONS > > See RFC 1342 comment. Codes are always US-ASCII. I don't understand what "Codes are always US-ASCII." means. Maybe something like this? The language codes and the language variant codes are restricted to the letters of US-ASCII, since they should be internationally usable and should, if possible, be based on the names of languages in English. Otherwise codes should be based on a name in another language, transliterated to English. Comments can be given in any MIME character set, though. It is anticipated that MIME-reading programs will translate the short language codes to full language names in a language suitable for the human reader. -- Olle Jarnefors, Royal Institute of Technology, Stockholm From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 12:07:18 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07862; Thu, 4 Nov 93 11:41:37 EST Received: from is.rice.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07858; Thu, 4 Nov 93 11:41:36 EST Received: from rita-blanca.is.rice.edu by is.rice.edu (AA07812); Thu, 4 Nov 93 10:41:33 CST Received: by rita-blanca.is.rice.edu (AA00498); Thu, 4 Nov 93 10:41:32 CST Date: Thu, 4 Nov 1993 10:38:27 -0600 (CST) From: Rick Troth Subject: Re: Priority header values To: Frank Bieser Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311041442.AA04214@floyd> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 4 Nov 1993, Frank Bieser wrote: > Sorry to interrupt the MIME discussions, but I cannot, for my life, > find where the Priority: mail header is defined. Are you thinking of the "Precedence:" header? > -- Frank Bieser (frankb@hal.com) -- Rick Troth , Rice University, Information Systems From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 13:06:02 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07823; Thu, 4 Nov 93 11:40:46 EST Received: from dxmint.cern.ch by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07819; Thu, 4 Nov 93 11:40:42 EST Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04363; Thu, 4 Nov 1993 17:40:34 +0100 Received: by www3.cern.ch (NX5.67c/NX3.0S) id AA05009; Thu, 4 Nov 93 17:34:41 +0100 Date: Thu, 4 Nov 93 17:34:41 +0100 From: Tim Berners-Lee Message-Id: <9311041634.AA05009@www3.cern.ch> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu Subject: Web and Mail integration: a few key connections. Cc: ietf@cnri.reston.va.us Reply-To: timbl@nxoc01.cern.ch There are currently two worlds in the IETF which ought to collide: the multimedia information access world, epitomized by the WWW architecture, and the RFC822+MIME world of mail. Sorry about the hastily scribbled nature of this note about tying it all together. I send it to the entire IETF list because there has been criticism in the past that ideas have not been aired widely enough. Background ========== The Web is the world of information accessible instantly on request. WWW uses Uniform Resource Identifiers (URIs, see URL ID) to unify many protocols, but it also has its own protocol (HHTP, ID coming out) which has features needed for a clean and complete system. URIs are sometimes divided into URLs (Locators) which refer to the use of a particular protocol for aceess, and URNs (names) which don't. Lots of URLs are defined, no URNs. RFC822 is basic Internet mail, and MIME describes how multimedia can be represented for mail. HTTP is a request/response stateless internet-style protocol, which transmits objects around as MIME messages (except allowing binary transport). HTTP has a bunch of headers for metainformation in addition to the MIME ones. These are "URC" information in terminology of the URI working group. WWW defines one (soon two) SGML document types for sending around basic hypertext (+graphics). The first, "HTML", explicitly uses URIs of other objects in hypertext links. (See HTML ID) There has been some discussion recently about how to send SGML documents along with DTDs and oetr things which they reference in MIME messages. (see SGML-MIME ID). SGML documents refer to external entities as either "PUBLIC", in which case a special "Formal Public Identifier" (FPI) space is used and everyone is supposed o know what's in it, or "SYSTEM" in which case the significance is purely local. Proposals ========= My suggestions for tying this all togther are: 1. In an Internet context, the SGML "SYSTEM" identifiers should be conventionally URIs. As there are URIs which refer to a local file system, this does not rule out refering to local files too. 2. The FPI space should be registered as a URN. 3. Some space inside FPI space should be found for the URN tree as well. 4. For the case of mail transport, both message-id values (identifeirs of mail messages) and content-ids (identifiers of parts of a multpart MIME message) should be registered as URNs. They will of course only be dereferencable by people who have been sent the relevant mail, but that is fine. Now we have URI schemes fpi: cid: mid: 5. The convention is adopted that when a multipart/related document is sent, that the first part is consuleted for information about the relationships. HTML allows links to be made and also allows the relationships to be given between parts. 6. The metainformation headers in HTTP should be adopted as the URC format for the URI working group, with suitable discussion and additions. This will allow, using the Link: header which is isomorphous to the HTML element, relationships to be defined between non-HTML pars of a MIME multipart/related document. 7. HTTP should be specified to include support for MIME multipart/related, to solve the problem of servers which like to send a document with all its included graphics in one respone. Acceptance of multipart/related could be made mandatory or subject to the Accept: multipart/related header in the HTTP request. I think that's everything. References for working documents and discussion lists: ========== URI, URL: ftp://ftp.internic.net/internet-drafts/draft-ietf-uri-url-01.ps mailto:uri-request@bunyip.com HTML: ftp://ftp.internic.net/internet-drafts/draft-ietf-iiir-html-01.ps mailto:www-talk-request@info.cern.ch HTTP: ftp://info.cern.ch/pub/www/doc/http-spec.ps mailto:www-talk-request@info.cern.ch SGML-MIME: ftp://ftp.internic.net/internet-drafts/draft-ietf-mime-sgml-00.txt mailto: ietf-822-request@dimacs.rutgers.edu All .ps postscript files have plainascii .txt equivalents. All documents may be retrieved by URL by sending a message with a line "send " followed by the URL to robot@info.cern.ch Please send comments to specific lists only where you can! Tim Berners-Lee CERN From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 12:36:54 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07880; Thu, 4 Nov 93 11:42:18 EST Received: from dxmint.cern.ch by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07866; Thu, 4 Nov 93 11:42:15 EST Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04526; Thu, 4 Nov 1993 17:41:56 +0100 Received: by www3.cern.ch (NX5.67c/NX3.0S) id AA05014; Thu, 4 Nov 93 17:35:57 +0100 Date: Thu, 4 Nov 93 17:35:57 +0100 From: Tim Berners-Lee Message-Id: <9311041635.AA05014@www3.cern.ch> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: "Harald T. Alvestrand" Subject: Re: A spec for showing language in MIME headers Cc: ietf-822@dimacs.rutgers.edu, uri@bunyip.com Reply-To: timbl@nxoc01.cern.ch Harald, 1. Thanks for the proposal. 2. The HTTP protocol (ID should have come out in July but sorry it got lost, now in the pipeline, and available as ftp://info.cern.ch/www/doc/http-spec.{ps,txt}) has a bunch of extended metainformation needed by WWW when it returns things from or send things to a real time (as opposed to mail) server. WWW as you may know uses MIME messages as protocol data units (kinda), but with extenstions. 3. The HTTP spec includes a "Language:" field, with basically the same spec as Content-Language:. Can I ask why the "Content-"? The metainformation in RFC822 headers always applies to the message, not to the header. Is this a little like putting lables on the jelly jar, "Jelly Jar" or "Jelly Jar Label" instead of simply "Jelly"? 4. The HTTP protocol also addresses the question of variants, including currently Language:, Content-Type:, and Version. There is a mecahnism for the client to say what content-type and languge he can accept, and there is a mechanism to say, in a URI which is given for an object, in which dimensions variants of the object are still refered to by the URI. I have jsut sent aorund a message about tying all this togther whoich provides a way for a first alternate part to give (using URI fields which refer to content-identifiers) the relationships between the alternate parts. Tim BL From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 13:36:03 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11955; Thu, 4 Nov 93 13:08:24 EST Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11951; Thu, 4 Nov 93 13:08:23 EST Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4WW0Z4APC9BVGF9@INNOSOFT.COM>; Thu, 4 Nov 1993 10:02:54 PST Date: Thu, 04 Nov 1993 10:02:24 -0800 (PST) From: Ned Freed Subject: Re: Priority header values In-Reply-To: Your message dated "Thu, 04 Nov 1993 08:42:25 -0600 (CST)" <9311041442.AA04214@floyd> To: frankb@hal.com Cc: ietf-822@dimacs.rutgers.edu Message-Id: <01H4WWJSKGAI9BVGF9@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > Sorry to interrupt the MIME discussions, but I cannot, for my life, > find where the Priority: mail header is defined. I've searched through > the RFC archives, and only find references to it, claiming it is defined > in 822. But it is not; at least not in my copy. Could some kind soul > point me to where I can find a defined range of values for this > beasty? Check out RFC1327 for the definition. Ned From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 18:36:05 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15464; Thu, 4 Nov 93 18:09:05 EST Received: from Delphi.CS.UCLA.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15460; Thu, 4 Nov 93 18:09:03 EST Received: from twinsun.UUCP by delphi.cs.ucla.edu (Sendmail 5.61d+YP/3.21ns) id AA22005; Thu, 4 Nov 93 15:09:01 -0800 Received: by twinsun.com (4.1/SMI-4.1) id AA15758; Thu, 4 Nov 93 14:12:20 PST Received: from ford.airco.co.jp by air.airco.co.jp (4.1/6.4J.6) id AA13206; Thu, 4 Nov 93 10:11:36 JST Received: from ford (localhost) by ford.airco.co.jp (4.1/6.4J.6) id AA13103; Thu, 4 Nov 93 10:00:21 JST Return-Path: Message-Id: <9311040100.AA13103@ford.airco.co.jp> Date: Thu, 4 Nov 1993 10:00:18 +0900 (JST) From: Mark Keasling Reply-To: Mark A Keasling Subject: Re: Text/enriched ambiguity To: beyond!eng!tcrowley@uunet.uu.net Cc: ietf-822@dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 02 Nov 93 09:52:18 EDT, beyond!eng!tcrowley@uunet.uu.net wrote... > > >> It is my opinion, though I'm not an authority on such matters, that the > simple > >> approach would be that a parser should not attempt to parse the contents > of a > >> ... command section. Since the simple parser doesn't > understand > >> the contents of the section anyway, what does it gain by > pretending > >> that it does? > > You have to parse the contents, because you need to be able to > recognize the end of the block. Parse is actually too strong a > word - its really just lexical analysis. > [stuff deleted] > Terry What I meant is that if you had some enriched text like: .. some text some more text ... 1. a simple parser could simply look for the after the and continue as if param was comment renamed. 2. a simple parser could use the command matching rules and try to to match with , with and with but since it finds a then it must be able to handle the error condition, generating error messages and what not. I would argue for option 1. Of course there may be other options. So instead of trying to make sense of the contents of the param block since they are used to contain some application specific information anyway, I think that parsing/lexical analysis of the contents by a simple parser should be limited to finding the . PS. Please, use my address in the Reply-To: header as I get nasty grams like this otherwise: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NOTICE! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> InetClub in Japan must pay the cost for this email: >> From: uunet!beyond!eng!tcrowley To: makr@air.airco.co.jp >> It would be greatly appreciated if the sender would check the recipi- >> >> ent address again before sending further mails. >> >> Senders or recipients in the .jp domain should be members of InetClub. >> >> ----------------------------------------------------------------------->> >> InetClub operation is based on a member's fee. >> >> For further information, please contact the following: >> >> Tel: +81 3-3347-9236 E-mail: member@kddlab.kddlabs.co.jp >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, -- Mark Keasling AIR Company LTD, Nishikawa Mitsui Bldg, 1-3-14 Kitahama, Chuo-ku, Osaka 541 email: makr%air@unify.com phone: +1 81 6201 4307 fax: +1 81 6201 2107 From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 20:36:06 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15928; Thu, 4 Nov 93 20:06:52 EST Received: from zoo.utoronto.ca by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA15924; Thu, 4 Nov 93 20:06:50 EST Message-Id: <9311050106.AA15924@dimacs.rutgers.edu> From: henry@zoo.toronto.edu Date: Thu, 4 Nov 93 20:06:38 EST To: 822 Subject: Re: comment on draft-vandreuil-mime-sig-00.txt In-Reply-To: <9311040845.AA17208@skidrow.lkg.dec.com> >It is also common for "/" to occur in Mail Stops. Mine at DEC is >LKG2-1/BB3. Also, in some places it is used as a separator between street number and apartment number. I have a friend in Australia whose address is "2/65 XYZ St." -- that's apartment 2 at 65 XYZ St. Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry From owner-ietf-822@dimacs.rutgers.edu Thu Nov 4 22:06:07 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19808; Thu, 4 Nov 93 21:55:33 EST Received: from PO3.ANDREW.CMU.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19804; Thu, 4 Nov 93 21:55:32 EST Received: from localhost (postman@localhost) by po3.andrew.cmu.edu (8.5/8.5) id VAA15554; Thu, 4 Nov 1993 21:55:28 -0500 Received: via switchmail; Thu, 4 Nov 1993 21:55:27 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 4 Nov 1993 21:55:10 -0500 (EST) Received: from hogtown.andrew.cmu.edu via qmail ID ; Thu, 4 Nov 1993 21:55:07 -0500 (EST) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4m.412 via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411; Thu, 4 Nov 1993 21:55:05 -0500 (EST) Message-Id: Date: Thu, 4 Nov 1993 21:55:05 -0500 (EST) From: John Gardiner Myers Subject: Re: Text/enriched ambiguity To: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311040100.AA13103@ford.airco.co.jp> References: <9311040100.AA13103@ford.airco.co.jp> Beak: Is I shouldn't be confusd with someone who has intimate knowledge about full-blown SGML. My expertise is much more focused on Internet mail. I agree with Mark Keasling in that it is best to think of as gratuitously renamed. I believe the wording of the draft spec supports that view and that view makes it easier to write a parser that can deal with both richtext and enriched depending on a mode variable. I don't think anyone has made a convincing case that there are any real advantages of any other view. In text/richtext, could nest--when parsing it, you had to at least tokenize everything, recognize and commands, and keep a depth count. That minimal requirement on parsers also exists in text/enriched. The restrictions placed on composers of text/enriched should necessarily be stricter than the requirements made of parsers. A parser that chose to do so should be able to continue to maintain a command stack and merely turn off output while inside . To allow parsers to choose this strategy when it is convenient for them to do so, composers should have the same command nesting restrictions inside as they do outside . -- _.John G. Myers Internet: jgm+@CMU.EDU LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up From owner-ietf-822@dimacs.rutgers.edu Fri Nov 5 00:36:08 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20235; Fri, 5 Nov 93 00:30:47 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA20231; Fri, 5 Nov 93 00:30:29 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 5 Nov 93 14:24:37 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311050524.AA14537@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headers To: ojarnef@admin.kth.se (Olle Jarnefors) Date: Fri, 5 Nov 93 14:24:35 JST Cc: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se In-Reply-To: <9311041410.AA18473@mercutio.admin.kth.se>; from "Olle Jarnefors" at Nov 4, 93 3:10 pm X-Mailer: ELM [version 2.3 PL11] Content-Language: ISO_se I'm not sure whether I can understand ISOish with US_ASCII, but... > I suppose this doesn't exclude using "charset" with some other > semantics than the usual in the definition of some new > content-type. Of course. But, so what? > Perhaps we should then also have a Content-Filename-Suggestion: > header for those many cases where it's appropriate to save the > body of a body-part in a file? And a Header-Filename-Suggestion: > for saving the header of the body-part? And a Content-Filename-Suggestion-Language: and a Header-Filename- Suggestion-Language: and Content-Filename-Suggestion-Supplemental-Language: and a Header-Filename-Suggestion-Supplimental-Language: and..... > especially in the case of a text object, to allow for a speech > synthesis system to automatically select the right dialect OK. Your speech synthesis system should be of quite high quality. MO From owner-ietf-822@dimacs.rutgers.edu Fri Nov 5 07:06:10 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22112; Fri, 5 Nov 93 06:50:37 EST Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22108; Fri, 5 Nov 93 06:50:36 EST Received: from guppylake.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-822@dimacs.rutgers.edu; Fri, 5 Nov 93 06:49:02 EST Received: by guppylake.bellcore.com (4.1/4.7) id for uri@bunyip.com; Fri, 5 Nov 93 06:42:19 EST 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; Fri, 5 Nov 1993 06:42:18 -0500 (EST) Message-Id: Date: Fri, 5 Nov 1993 06:42:18 -0500 (EST) From: Nathaniel Borenstein To: "Harald T. Alvestrand" , timbl@nxoc01.cern.ch Subject: Re: A spec for showing language in MIME headers Cc: ietf-822@dimacs.rutgers.edu, uri@bunyip.com In-Reply-To: <9311041635.AA05014@www3.cern.ch> References: <9311041635.AA05014@www3.cern.ch> Excerpts from mail: 4-Nov-93 Re: A spec for showing lang.. Tim Berners-Lee@www3.cer (1393) > Can I ask why the "Content-"? Probably to make it clear that it applies to body-parts. In general, the only header fields that apply to MIME body parts (as opposed to a top-level message or an encapsulated message) are the Content-* ones. -- NB From owner-ietf-822@dimacs.rutgers.edu Fri Nov 5 09:08:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22827; Fri, 5 Nov 93 08:56:40 EST Received: from mail.nada.kth.se by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22823; Fri, 5 Nov 93 08:56:38 EST Received: from arnold.ietf28.sesqui.net by mail.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA21536; Fri, 5 Nov 93 14:56:11 +0100 Message-Id: <9311051356.AA21536@nada.kth.se> X-Sender: paf@mail.nada.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 1993 07:57:00 -0600 To: Masataka Ohta , ojarnef@admin.kth.se (Olle Jarnefors) From: paf@nada.kth.se (Patrik Faltstrom) Subject: Re: A spec for showing language in MIME headers Cc: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se Masataka Ohta writes: >> Perhaps we should then also have a Content-Filename-Suggestion:= =20 >> header for those many cases where it's appropriate to save the= =20 >> body of a body-part in a file? And a Header-Filename-Suggestion:= =20 >> for saving the header of the body-part? > >And a Content-Filename-Suggestion-Language: and a Header-Filename- >Suggestion-Language: and Content-Filename-Suggestion-Supplemental-Language: >and a Header-Filename-Suggestion-Supplimental-Language: and..... In most of the content-types there is an optional parameter, NAME,= which tells you what the filename is. This is only a suggestion, i.e. what Olle wants. The problem with filenames, as we all know, is that the specification in which way you write a filename differs very much between different operating systems. paf ------------------------------------------------------------------------- Patrik F=E4ltstr=F6m Tel Nat 08-7906274 Email: paf@nada.kth.= se NADA, KTH Int +46-8-7906274 S-100 44 STOCKHOLM Fax +46-8-7900930 SWEDEN From owner-ietf-822@dimacs.rutgers.edu Sun Nov 7 19:06:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28236; Sun, 7 Nov 93 18:44:21 EST Received: from THOR.INNOSOFT.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28232; Sun, 7 Nov 93 18:44:19 EST Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1234) id <01H4ZPMTZFJ49BVGZP@INNOSOFT.COM>; Sun, 7 Nov 1993 15:43:58 PST Date: Sun, 07 Nov 1993 15:14:07 -0800 (PST) From: Ned Freed Subject: Re: Web and Mail integration: a few key connections. In-Reply-To: Your message dated "Thu, 04 Nov 1993 17:34:41 +0100" <9311041634.AA05009@www3.cern.ch> To: Tim Berners-Lee Cc: iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu Message-Id: <01H51FBPA57K9BVGZP@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > There has been some discussion recently about how to > send SGML documents along with DTDs and oetr things > which they reference in MIME messages. (see SGML-MIME ID). > SGML documents refer to external entities > as either "PUBLIC", in which case a special "Formal > Public Identifier" (FPI) space is used and everyone > is supposed o know what's in it, or "SYSTEM" in which > case the significance is purely local. My understanding is that there's one level of indirection implicit in SGML to begin with. Specifically, the actual documents references things by names which are then bound to actual objects by the DTD. > 1. In an Internet context, the SGML "SYSTEM" identifiers > should be conventionally URIs. As there are URIs > which refer to a local file system, this does not > rule out refering to local files too. This sounds like a good idea to me. > 2. The FPI space should be registered as a URN. As I understand it, the FPI space has a lot in common with several other things in OSI. Specifically, while it does provide a convenient space for public usage, the lack of any authoritative registration process makes it very difficult for things to really interoperate. (Many other aspects of OSI have similar problems, such as BP15 OID usage, FTAM file formats, and so on.) Given that this is a fair representation of the current situation, I think having the Internet provide such a process would be a wonderful thing. In addition, if that process can be piggybacked on top of some existing or soon-to-exist scheme like URNs, so much the better. > 3. Some space inside FPI space should be found for > the URN tree as well. I'm not sure how you'd do this in any authoritative way. Any SGML experts (I'm certainly nothing of the kind) care to comment? > 4. For the case of mail transport, both message-id values > (identifeirs of mail messages) and content-ids > (identifiers of parts of a multpart MIME message) > should be registered as URNs. They will of course > only be dereferencable by people who have been > sent the relevant mail, but that is fine. Are these really URNs? Aren't they actually URIs since the access method is implicit in the name? > 5. The convention is adopted that when a multipart/related > document is sent, that the first part is consuleted for > information about the relationships. Expect to see some documents clarifying the handling of multipart MIME objects in the near future. > 7. HTTP should be specified to include support > for MIME multipart/related, to solve the problem > of servers which like to send a document with all > its included graphics in one respone. Interesting idea. I like it. I think we also need some kind of message subtype in MIME that does things similar to message/external-body but resolves URIs and/or URNs. I don't see this as being something that can be just another access-type under message/external-body because of the semantics peculiar to the HTTP way of resolving URIs (specifically, that the content-type is selected by the server in response to what the client indicates it can handle). Ned From owner-ietf-822@dimacs.rutgers.edu Sun Nov 7 21:06:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28760; Sun, 7 Nov 93 20:50:36 EST Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA28756; Sun, 7 Nov 93 20:50:35 EST Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA11656; Sun, 7 Nov 93 20:49:53 -0500 Message-Id: <9311080149.AA11656@thud.cs.utk.edu> From: Keith Moore To: Ned Freed Cc: Tim Berners-Lee , iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: Web and Mail integration: a few key connections. In-Reply-To: Your message of "Sun, 07 Nov 1993 15:14:07 PST." <01H51FBPA57K9BVGZP@INNOSOFT.COM> Date: Sun, 07 Nov 1993 20:49:51 -0500 Sender: moore@cs.utk.edu Ned writes... > I think we also need some kind of message subtype in MIME that does things > similar to message/external-body but resolves URIs and/or URNs. I don't see > this as being something that can be just another access-type under > message/external-body because of the semantics peculiar to the HTTP way of > resolving URIs (specifically, that the content-type is selected by the > server in response to what the client indicates it can handle). There is a need for a URN-like thing that can be absoultely tied to a particular format of an object. Without such a URN there is no way to cache/replicate objects correctly. This doesn't preclude HTTP (or gopher, or whatever) from doing "conversion" from a primary format to another format on behalf of the client. A properly designed URN/URL system would not prevent use of MIME's message/external-body with URNs, though it might not allow conversion on-the-fly in this case. Keith From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 03:36:41 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04802; Mon, 8 Nov 93 03:34:23 EST Received: from domen.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04798; Mon, 8 Nov 93 03:34:17 EST Message-Id: <9311080834.AA04798@dimacs.rutgers.edu> Received: from localhost by domen.uninett.no with SMTP (PP) id <12353-0@domen.uninett.no>; Mon, 8 Nov 1993 09:34:10 +0100 To: timbl@nxoc01.cern.ch Cc: ietf-822@dimacs.rutgers.edu, uri@bunyip.com Subject: Re: A spec for showing language in MIME headers In-Reply-To: Your message of "Thu, 04 Nov 1993 17:35:57 +0100." <9311041635.AA05014@www3.cern.ch> Date: Mon, 08 Nov 1993 09:34:08 +0100 From: "Harald T. Alvestrand" Tim, thanks for the comment! I hope we can make sure that the WWW definition is the same as the "official" one (whether amending one or the other). The content- piece got into there for 2 reasons: 1) The language in RFC 1521 says: Global mechanisms are best addressed, in the MIME model, by the definition of additional Content-* header fields. Also, in chapter 7.2 (Multipart): A body part is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header field implies that the corresponding body is plain US-ASCII text. The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields are generally to be ignored in body parts. Although they should generally be retained in mail processing, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but must not be depended on. "X-" fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways. 2) The Language: parameter is defined in RFC 1327, with slightly different semantics (only one language permitted). Reusing existing names with a slightly incompatible interpretation can get painful, so I would like to opt for a new name. Harald A From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 04:06:42 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04895; Mon, 8 Nov 93 03:46:51 EST Received: from domen.uninett.no by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04891; Mon, 8 Nov 93 03:46:49 EST Message-Id: <9311080846.AA04891@dimacs.rutgers.edu> Received: from localhost by domen.uninett.no with SMTP (PP) id <12479-0@domen.uninett.no>; Mon, 8 Nov 1993 09:46:44 +0100 To: Olle Jarnefors Cc: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headers In-Reply-To: Your message of "Thu, 04 Nov 1993 15:10:48 +0100." <9311041410.AA18473@mercutio.admin.kth.se> Date: Mon, 08 Nov 1993 09:46:40 +0100 From: "Harald T. Alvestrand" Olle, thanks for the *BEAUTIFUL* comments! I'll probably import most of them by copy-paste! The reason for using _ instead of - as separator was because of the POSIX "locale" convention - keeping our distance from this is probably as good an idea as copying it. I think the main structure of the tagging should now be: - where may be: - an ISO 639 language code (of whatever version; make a note that 3-letter languages are expected in a later ISO 639 version) - The single letter "X" for private extensions - The four-letter string "IANA" for IANA registered extensions The may be: - An ISO 3166 2-letter country code - An IANA-registered variant of 3 or more characters - A private-use variant starting with "X-". When the is "X", the "Variant" is always a private use one. (Writing X-X-something is too ridiculous) Thus, the following are all legal, if IANA registrations are done: en-cockney ("cockney" being IANA registered) smi-FI (after new 639 registers "smi" only) no-x-bergensk iana-klingon (not likely that ISO will register this :-) x-highelven Personally, I think that the extension mechanism will be mostly left unused, as John Klensin experienced in a similar project earlier, but when you need it, you REALLY need it. (John, do you want to comment? I don't remember an exact reference) To Ohta-san: This is the way we always work, I think: Building little pieces on top of other pieces, so that we can get our work done. Nothing new in that. Harald A From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 05:36:42 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05428; Mon, 8 Nov 93 05:21:35 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05424; Mon, 8 Nov 93 05:21:23 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Nov 93 19:15:04 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311081015.AA26352@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headers To: Harald.T.Alvestrand@uninett.no (Harald T. Alvestrand) Date: Mon, 8 Nov 93 19:15:02 JST Cc: ojarnef@admin.kth.se, ietf-822@dimacs.rutgers.edu In-Reply-To: <9311080846.AA04891@dimacs.rutgers.edu>; from "Harald T. Alvestrand" at Nov 8, 93 9:46 am X-Mailer: ELM [version 2.3 PL11] > I think the main structure of the tagging should now be: > > - > > where may be: > > - an ISO 639 language code (of whatever version; make a note that > 3-letter languages are expected in a later ISO 639 version) > > - The single letter "X" for private extensions > > - The four-letter string "IANA" for IANA registered extensions I bet my 0.001 Yen that, in the future version of ISO 639, language names "X" or "IANA" will be registered. > To Ohta-san: This is the way we always work, I think: I know what is your work. > Building little > pieces on top of other pieces, so that we can get our work done. > Nothing new in that. Building large piece of documents on top of other already huge pieces and your work is done. The implementation is someone else's problem, of course. I'm afraid you don't mind if thw work is useful only for the group of proffessional Linguists who shares a single doctrine of linguistics. Masataka Ohta From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 06:36:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05681; Mon, 8 Nov 93 06:09:24 EST Received: from dxmint.cern.ch by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05677; Mon, 8 Nov 93 06:09:21 EST Received: from www3.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19498; Mon, 8 Nov 1993 12:09:16 +0100 Received: by www3.cern.ch (NX5.67c/NX3.0S) id AA07661; Mon, 8 Nov 93 12:03:19 +0100 Date: Mon, 8 Nov 93 12:03:19 +0100 From: Tim Berners-Lee Message-Id: <9311081103.AA07661@www3.cern.ch> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Keith Moore Subject: Re: Web and Mail integration: a few key connections. Cc: iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Reply-To: timbl@nxoc01.cern.ch >There is a need for a URN-like thing that can be absoultely tied to a >particular format of an object. Without such a URN there is no way to >cache/replicate objects correctly. (URN-like thing =~ "URI", the generic identifier) The HTTP spec has, in the object metainfo, a URI: header. It specifies a URI for the object. The "vary=" parameter of this header specifies whether the URI refers to the exact binary pattern, or whether it can refer to "variants" of language, content-type or version. (These are the only variants curerntly explicit, one can imagine others) Caching systems obviously use this information intelligently to know whether they have a copy verbatim of an object or a copy of one instance of a generic object. Tim From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 07:06:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05750; Mon, 8 Nov 93 06:23:39 EST Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05746; Mon, 8 Nov 93 06:23:37 EST Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H528Y558I8000ZW2@INFOODS.UNU.EDU>; Mon, 8 Nov 1993 06:23:06 EST Date: Mon, 08 Nov 1993 06:23:06 -0500 (EST) From: John C Klensin Subject: Re: A spec for showing language in MIME headers In-Reply-To: <9311080846.AA04891@dimacs.rutgers.edu> To: Harald.T.Alvestrand@uninett.no Cc: ojarnef@admin.kth.se, ietf-822@dimacs.rutgers.edu Message-Id: <752757786.458731.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: My copy of the original message seems to have gotten lost in the mail storm of the last few weeks (might turn up yet), but as far as I can deduce from your comments, Harald, it seems plausible. In principle, it could result in IANA having to register a very large number of languages that do not appear in ISO 639. But that would probably be ok if it happened. And, unless folks give into the temptation to show off how smart they are by registering languages that are not actually used in email communications, it won't happen in practice. john From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 07:36:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05779; Mon, 8 Nov 93 06:43:12 EST Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05775; Mon, 8 Nov 93 06:43:11 EST Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H528Y558I8000ZW2@INFOODS.UNU.EDU>; Mon, 8 Nov 1993 06:41:56 EST Date: Mon, 08 Nov 1993 06:41:55 -0500 (EST) From: John C Klensin Subject: Re: A spec for showing language in MIME headers In-Reply-To: <9311081015.AA26352@necom830.cc.titech.ac.jp> To: mohta@necom830.cc.titech.ac.jp Cc: Harald.T.Alvestrand@uninett.no, ojarnef@admin.kth.se, ietf-822@dimacs.rutgers.edu Message-Id: <752758915.723731.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: > I bet my 0.001 Yen that, in the future version of ISO 639, language names > "X" or "IANA" will be registered. I would probably agree about "XX" or "IAN". But ISO/TC46 tends to like uniformity in their schemes and, since they have never contemplated single-character registrations, and it has taken them more than a decade to become serious about moving to three characters, we are probably reasonably safe. If people wanted to be completely safe, "IANA-" would be spelled, e.g., "*-", just it get it to one unambigious character that will never be registered under any plausible scenario. >I'm afraid you don't mind if thw work is useful only for the group of >proffessional Linguists who shares a single doctrine of linguistics. Could you explain this comment? I don't think I see any problem as long as good sense is used and the essentially arbitrary nature of this type of classification is understood. I would like to see IANA given guidance about what not to register, e.g., that one doesn't register one 639 language as a variant on another and that sufficient description comes in to avoid clearly-redundant registrations, but, other than that... As we have discussed in other contexts, I don't think this sort of thing is good enough for the finely-tuned discussions of professional linguists who are trying to do comparative work. But my standing hypothesis assumes that community will need the capability for *much* more precise labelling, potentially on a per-word or per-phrase basis, that is provided, e.g., by the TEI's use of SGML, rather than per-message labels. Since the original message has not yet caught up with me, I don't have a clear picture of what problem this proposal is intended to fix. Those who remember my Content-language pre-proposal of last spring will recall that it was addressed to things like selection among multipart alternatives, rather than solving, e.g., the distinction between Chines and Japanese use of Han-derived characters. john From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 08:06:44 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05944; Mon, 8 Nov 93 07:31:32 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05940; Mon, 8 Nov 93 07:31:19 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 8 Nov 93 21:25:13 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311081225.AA27060@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headers To: KLENSIN@infoods.mit.edu (John C Klensin) Date: Mon, 8 Nov 93 21:25:11 JST Cc: Harald.T.Alvestrand@uninett.no, ojarnef@admin.kth.se, ietf-822@dimacs.rutgers.edu In-Reply-To: <752758915.723731.KLENSIN@INFOODS.UNU.EDU>; from "John C Klensin" at Nov 8, 93 6:41 am X-Mailer: ELM [version 2.3 PL11] > > I bet my 0.001 Yen that, in the future version of ISO 639, language names > > "X" or "IANA" will be registered. > > I would probably agree about "XX" or "IAN". But ISO/TC46 tends to like > uniformity in their schemes and, since they have never contemplated > single-character registrations, and it has taken them more than a decade > to become serious about moving to three characters, we are probably > reasonably safe. Unless ISO maliciously tries to do so, yes, probably. Anyway, as 26*26*26+26*26=18252, the 2 or 3 letter space is not large enough to give meaningful names to all the languages in the world. The country name is useful to disambiguate english between several countries but not so useful in general as the most of the not-so-famous languages are used within a single country. > >I'm afraid you don't mind if thw work is useful only for the group of > >proffessional Linguists who shares a single doctrine of linguistics. > > Could you explain this comment? For example, how can you measure the difference between en-cockney, en-au, current en-gb and en-gb 300 years ago? > I would like to see IANA given > guidance about what not to register, e.g., that one doesn't register one > 639 language as a variant on another and that sufficient description > comes in to avoid clearly-redundant registrations, but, other than > that... Without a single doctrine, how can IANA recognize something is "cleary-redundant"? I think it inappropriate to expect IANA judge highly pedantic and political issues. Also, it is impractical to use country codes. They are quite unstable that it can not be used without time stamp. Also, 3166 can not be used to currently-non-existing countries. That's why I proposed that the distinction should be by location and by time. A possible improvement is to allow mnemonic IANA registration as an acronym of location and time, nothing more than that and let pedantic and political issues be confined in 639. > Since the original message has not yet caught up with me, I don't have a > clear picture of what problem this proposal is intended to fix. That is my problem too. If ISO is revising 639, why can't we use the revised one as is? Unless we know why we need detailed extension, we can't design how the extension should be. > Those > who remember my Content-language pre-proposal of last spring will recall > that it was addressed to things like selection among multipart > alternatives, rather than solving, e.g., the distinction between Chines > and Japanese use of Han-derived characters. So, if we need selection among multipart alternatives, isn't revised 639 enough? If not, why? Masataka Ohta From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 12:43:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10415; Mon, 8 Nov 93 12:12:46 EST Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA10411; Mon, 8 Nov 93 12:12:42 EST Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H52LAOQ0I800101J@INFOODS.UNU.EDU>; Mon, 8 Nov 1993 12:11:23 EST Date: Mon, 08 Nov 1993 12:11:23 -0500 (EST) From: John C Klensin Subject: Re: A spec for showing language in MIME headers In-Reply-To: <9311081225.AA27060@necom830.cc.titech.ac.jp> To: mohta@necom830.cc.titech.ac.jp Cc: Harald.T.Alvestrand@uninett.no, ojarnef@admin.kth.se, ietf-822@dimacs.rutgers.edu Message-Id: <752778683.166731.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: > For example, how can you measure the difference between en-cockney, en-au, > current en-gb and en-gb 300 years ago? When it is important, this is exactly the sort of question that I think should drive us toward TEI-like techniques. Those techniques are clearly internal to a content type and below the level of a MIME content type (unless we needed, e.g., text/tei-sgml to indicate that level of encoding was taking place). >> Since the original message has not yet caught up with me, I don't have a >> clear picture of what problem this proposal is intended to fix. > >That is my problem too. If ISO is revising 639, why can't we use the >revised one as is? Let me restate this, but I'm assuming that we are in substantial agreement: -- For the indentification of major languages that are likely to be used in "plain text" email, 639 (or 636bis) probably suffices. -- For major languages that are used in email but that don't appear in 639, we may be better off encouraging registration in 639, rather than inventing an Internet-specific (e.g., IANA) mechanism. -- For very complex cases, requiring the specific identification of dialect, location, time, etc., nothing with the granularity of "body part" is likely to suffice, and we need coding techniques that can identify the origins/context of particular words. The question then becomes whether there are cases that are (i) relatively simple, (ii) not covered by 639 or appropriate for registration, (iii) likely to be used in "plain text" email. If so, we should pursue Ole's suggestion. If not, it is solving a problem with a null set of cases. john From owner-ietf-822@dimacs.rutgers.edu Mon Nov 8 18:10:36 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17151; Mon, 8 Nov 93 17:58:08 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17147; Mon, 8 Nov 93 17:58:06 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Tue, 9 Nov 93 08:57:55 +1000 Date: Tue, 9 Nov 93 08:57:53 EST From: rhys@cs.uq.oz.au Message-Id: <9311082257.AA22459@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headers >> I would probably agree about "XX" or "IAN". But ISO/TC46 tends to like >> uniformity in their schemes and, since they have never contemplated >> single-character registrations, and it has taken them more than a decade >> to become serious about moving to three characters, we are probably >> reasonably safe. > >Unless ISO maliciously tries to do so, yes, probably. > >Anyway, as 26*26*26+26*26=18252, the 2 or 3 letter space is not large >enough to give meaningful names to all the languages in the world. Which is why the latest proposal doesn't have such limitations. If ISO-639 version 2539 has 100 letter codes, then Content-Language will be able to handle it. But at the moment, the 2-letter and future 3-letter codes are all we have, so that's all that are specified. Harald, it may be worth saying in your draft that languages codes are of arbitrary length (up to some suitably large maximum) and will change over time, so should not be hard-wired into a program, but appear in secondary configuration files instead. Or some such weasel wording. I suspect that long before all people of the world have access to e-mail communications, and want to use their own languages, that we'll all be speaking some Japano-English dialect anyway, and we'll only need one language code. :-) As for time-stamping: I think that is going a little overboard. We are talking about e-mail communications, with messages that have a fairly short life-time. Within the life-time of an e-mail message, the names of the languages and countries are not going to change all that much. Even if messages are stored in archives (as most of USENET is), then the Date: header on the messages is sufficient to say "country code xy as it was in 1993" if that kind of information is important. There is a need to cope with ancient languages and linguistic notations, but except for some twisted individuals who delight in "breaking the system", e-mail, in the form of text/*, is not the best way to do this. Rather some kind of marked-up document format would be better, especially since it is likely that explanatory text in a current language would be wrapped around the ancient writings or linguistic notations. This is beyond the scope of the IETF. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 01:40:39 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22462; Tue, 9 Nov 93 01:16:21 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22458; Tue, 9 Nov 93 01:16:13 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 9 Nov 93 15:10:54 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311090611.AA01363@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headers To: rhys@cs.uq.oz.au Date: Tue, 9 Nov 93 15:10:52 JST Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311082257.AA22459@client>; from "rhys@cs.uq.oz.au" at Nov 9, 93 8:57 am X-Mailer: ELM [version 2.3 PL11] > >> I would probably agree about "XX" or "IAN". But ISO/TC46 tends to like > >Anyway, as 26*26*26+26*26=18252, the 2 or 3 letter space is not large > >enough to give meaningful names to all the languages in the world. > Which is why the latest proposal doesn't have such limitations. If ISO-639 > version 2539 has 100 letter codes, then Content-Language will be able to > handle it. Here, we have, quite pedantically, been talking about the future possibility of having a 639 reigstered language "IANA", which destroys Harald's scheme. > I suspect that long before all people of the world have access to e-mail > communications, and want to use their own languages, that we'll all be > speaking some Japano-English dialect anyway, and we'll only need one > language code. :-) Say that to French. (^.^) > As for time-stamping: I think that is going a little overboard. We are > talking about e-mail communications, with messages that have a fairly short > life-time. Aren't we talking about a long term archive which contains data in MIME format? > Even if > messages are stored in archives (as most of USENET is), then the Date: header > on the messages is sufficient to say "country code xy as it was in 1993" > if that kind of information is important. If each compoents of a multipart message have separate Date: header, yes. Anyway, country code is not so useful to distinguish languages though there is notable exceptions of AU/GB/US English. > There is a need to cope with ancient languages and linguistic notations, but > except for some twisted individuals who delight in "breaking the system", > e-mail, in the form of text/*, is not the best way to do this. Rather some > kind of marked-up document format would be better, Isn't MIME rich text marked-up document? > especially since it is > likely that explanatory text in a current language would be wrapped around > the ancient writings or linguistic notations. This is beyond the scope of > the IETF. It seems to me that John C. Klensin is thinking about that possibility by tagging even individual words with langage names. Masataka Ohta From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 04:36:55 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23981; Tue, 9 Nov 93 04:16:27 EST Received: from INFOODS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23976; Tue, 9 Nov 93 04:16:25 EST Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id <01H536SJN0O0001188@INFOODS.UNU.EDU>; Tue, 9 Nov 1993 04:15:33 EST Date: Tue, 09 Nov 1993 04:15:33 -0500 (EST) From: John C Klensin Subject: Re: A spec for showing language in MIME headers In-Reply-To: <9311090611.AA01363@necom830.cc.titech.ac.jp> To: mohta@necom830.cc.titech.ac.jp Cc: rhys@cs.uq.oz.au, ietf-822@dimacs.rutgers.edu Message-Id: <752836533.501215.KLENSIN@INFOODS.UNU.EDU> X-Envelope-To: ietf-822@DIMACS.RUTGERS.EDU Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: >> especially since it is >> likely that explanatory text in a current language would be wrapped around >> the ancient writings or linguistic notations. This is beyond the scope of >> the IETF. > >It seems to me that John C. Klensin is thinking about that possibility >by tagging even individual words with langage names. Probably out of IETF scope. Certainly out of IETF competence. I was reporting on other (outside) work that has gone on for some time and is deployed. The point was only that individual word language-tagging and annotation is current practice among specialists and that we don't need to try to reinvent it. john From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 05:36:54 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24219; Tue, 9 Nov 93 05:17:13 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA24215; Tue, 9 Nov 93 05:17:10 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Tue, 9 Nov 93 20:17:03 +1000 Date: Tue, 9 Nov 93 20:17:02 EST From: rhys@cs.uq.oz.au Message-Id: <9311091017.AA25765@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headers >Here, we have, quite pedantically, been talking about the future >possibility of having a 639 reigstered language "IANA", which destroys >Harald's scheme. ISO would be very silly if they did this. Maybe we can alleviate the hassle by using "x-iana-*" rather than "iana-*", then everything that isn't handled by ISO will be prefixed by "x-". How about this Harald? >> Even if >> messages are stored in archives (as most of USENET is), then the Date: header >> on the messages is sufficient to say "country code xy as it was in 1993" >> if that kind of information is important. > >If each compoents of a multipart message have separate Date: header, yes. Depends on the archive. Is it storing messages or body parts? If messages, then the main Date: header is sufficient. If body parts, then it has probably already pulled off the enclosing MIME conventions, and some other mechanism will need to be used in the archive to record language tagging. If worst comes to worst, there is always the timestamp on the file in the archive. This may be hacky, but these are borderline cases, and we shouldn't be designing MIME solely for the borderline. Show me someone who wants to communicate daily in 16th century English or Japanese in e-mail, and you may convince me. 16th century attachments to the main message don't count. >> There is a need to cope with ancient languages and linguistic notations, but >> except for some twisted individuals who delight in "breaking the system", >> e-mail, in the form of text/*, is not the best way to do this. Rather some >> kind of marked-up document format would be better, > >Isn't MIME rich text marked-up document? Yes, but text/enriched is not intended to handle everything in the universe. Other formats (e.g. SGML) provide richer mark-up environments. It is possible to use Harald's language tags in text/enriched, but I would expect them to be for disambiguating CJK, etc for display purposes, rather than saying "the version of English spoken between 1500 and 1700 A.D.". At the moment, the only use I've seen for country codes is to select a speech synthesis unit for a particular dialect. Personally, hearing a message spoken in old English just because some joker put "en-1500" in the header doesn't impress me, and what should it do if it doesn't have a suitable dialect available? I'm also one of those Aussies who is likely to put an axe through my computer if it starts talking to me in "en-us" ( :-) ), so country codes should definitely be only if the dialect is very important IMHO. If date information is important, then lots of other info is likely to be important also. Bird quill fonts to simulate 16th century hand writing anyone? :-) Text/enriched is not the place for that: text/enriched is intended for day-to-day e-mail communication. During that day-to-day communication, it may be important to disambiguate CJK, but choosing an ancient font for display? Enough rambling for now. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 09:06:56 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25166; Tue, 9 Nov 93 09:00:43 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25151; Tue, 9 Nov 93 09:00:36 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 9 Nov 93 21:27:30 +0900 From: Masataka Ohta Return-Path: Message-Id: <9311091227.AA03675@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headers To: rhys@cs.uq.oz.au Date: Tue, 9 Nov 93 21:27:28 JST Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: <9311091017.AA25765@client>; from "rhys@cs.uq.oz.au" at Nov 9, 93 8:17 pm X-Mailer: ELM [version 2.3 PL11] > >Here, we have, quite pedantically, been talking about the future > >possibility of having a 639 reigstered language "IANA", which destroys > >Harald's scheme. > > ISO would be very silly if they did this. Unless there actually is a langage with a name "IANA" (quite unlikely). > Maybe we can alleviate the > hassle by using "x-iana-*" rather than "iana-*", then everything that isn't > handled by ISO will be prefixed by "x-". How about this Harald? Or "y-" or just "-*" or ... > >If each compoents of a multipart message have separate Date: header, yes. > > Depends on the archive. Is it storing messages or body parts? If messages, > then the main Date: header is sufficient. If all the parts share the same date. > This may be hacky, but these are borderline cases, and we shouldn't be > designing MIME solely for the borderline. Show me someone who wants to > communicate daily in 16th century English or Japanese in e-mail, and you > may convince me. 16th century attachments to the main message don't count. Time stamp is necessary if quite unstable contry names are used in the tag. Otherwise, if we don't have to consider languages in the year 2050 (not past but the future), we don't need the time stamp. > >Isn't MIME rich text marked-up document? > > Yes, but text/enriched is not intended to handle everything in the universe. > Other formats (e.g. SGML) provide richer mark-up environments. It is possible > to use Harald's language tags in text/enriched, but I would expect them to > be for disambiguating CJK, etc for display purposes, rather than saying > "the version of English spoken between 1500 and 1700 A.D.". As the CJK disambiguation is necessary word-by-word (don't forget that Harald proposes to handle multi-lingual document) and in header part, and the disambiguation is necessary only for the specific character set: ISO10646/UNICODE, language tag is not a good mechanism for the disambiguation. It's better to use ISO10646/UNICODE with the charset names "iso-10646-" for single language only. This policy is compatible with one of a directionality handling method discussed in the Houston MIME CONTENT BOF. That is, if we need directionality disambiguation for some encoding method, and if we need language disambiguation for another encoding method, and if we need some other disambiguation for yet another encoding method, it is better to encode it in the charset name than providing another subtypes. > At the moment, the only use I've seen for country codes is to select a > speech synthesis unit for a particular dialect. Personally, hearing a > message spoken in old English just because some joker put "en-1500" in > the header doesn't impress me, and what should it do if it doesn't > have a suitable dialect available? I'm also one of those Aussies who is > likely to put an axe through my computer if it starts talking to me in > "en-us" ( :-) ), so country codes should definitely be only if the dialect > is very important IMHO. My question, then, is 1) How will the revised 639 be? Are there anything like en-au separately registered in it? 2) If not, isn't it better to register "en-au" not as a contry code but just as an IANA registered language name? IANA registration can survive even after the contry name is deleted from ISO 3166. > If date information is important, then lots of other info is likely to be > important also. That is, I think it better to register "en-au" with a concrete IANA-registered-with-informational-RFC definition such as "English commonly used in Australia in 1993" than ambigously saying "English commonly used in Australia sometime". Masataka Ohta From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 16:10:52 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04441; Tue, 9 Nov 93 16:00:07 EST Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04434; Tue, 9 Nov 93 16:00:02 EST Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA17389; Tue, 9 Nov 93 15:59:47 -0500 Date: Tue, 9 Nov 93 15:59:45 -0500 From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headers Message-Id: In-Reply-To: our message <9311091017.AA25765@client> of Tue, 9 Nov 93 20:17:02 EST Content-Type: TEXT/plain; charset=US-ASCII rhys> Show me someone who wants to communicate daily in 16th rhys> century English or Japanese in e-mail, and you may rhys> convince me. You may have intended that as a rhetorical Q, but I am interpreting it as a challange. >:-)> Linguistic scholars, Classics Scholars, and Early Music scholars/enthusiasts are 3 categories that come to mind immediatly, all employ mail-lists and/or newsgroups and are doing research which commands respect, if not some degree of support. Also there are numerous groups with varied interest in alternate worlds from the literature of fantasy and science fiction: Narnia, Klingon... In fact there are large (100,000 +) groups of people who are doing both scholarly and informal research into all aspects of life ca 900-1600, including language (esp writing systems), there are mail-lists and newsgroups attempting to carry some of that burgeoning traffic. One of my roommates is researching Historical Japanese Names, and has of necessity explored some of the difficultys involved in typesetting Historical Kanji, in our discussions we have become convinced that a formally defined phrase-level markup (inline or not) of written-language-variants is a necessary precursor to successful polyglot-text transmission of written text. Yes, it will be a nasty can of worms to establish distinct categorys of usage, and I freely admit that we are not the proper commitee to make decisions on the categorization of specific glyphs. But we are clearly under significant (?self) presure to utilize the results of such work, IMHO we should be attempting to make some projection of need which would be useful in guideing future work. Even if we postulate a technically (and politically) successful unification of the worlds writing systems into a documented encoding, adoption of it will not be rapid or universal (witness present gateway issues), so some intermediary method of suggesting a writen-script-system for user display seems justified. Mind you I am not demanding font specifiers, perhaps font-class would be a better term. It would be usefull in selecting a font with appropriate encoding, but it wouldnt dictate any particular one. Audible selectors will have utility as well, but they deserve a seperate, probably similar apparatus. It is often the case that one writing system serves several spoken languages, occaisionally a spoken language has multiple writing systems available for its expression, so there is no one/one mapping here. And history does enter the equation, if for no other reason than that we cant ban historians from using the net. -- dana s emery From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 17:12:12 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04986; Tue, 9 Nov 93 16:57:55 EST Received: from ivory.educom.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04982; Tue, 9 Nov 93 16:57:53 EST Received: from [192.52.179.3] (conklin-mac.educom.edu) by ivory.educom.edu (5.65c/1.34 (EDUCOM)) id AA02060; Tue, 9 Nov 1993 16:57:45 -0500 Message-Id: <199311092157.AA02060@ivory.educom.edu> Date: Tue, 9 Nov 1993 16:58:06 -0500 To: ietf-822@dimacs.rutgers.edu From: conklin@ivory.educom.edu (Jim Conklin) X-Sender: conklin@educom.edu Subject: Re: A spec for showing language in MIME headers Dana S Emery writes: >rhys> Show me someone who wants to communicate daily in 16th >rhys> century English or Japanese in e-mail, and you may >rhys> convince me. > >You may have intended that as a rhetorical Q, but I am >interpreting it as a challange. >:-)> > Dana, I think your case is remarkably compelling, and I wonder if you're perhaps sufficiently expert (and/or sufficiently motivated <:-)> ) to be the person to suggest how this might be done? That's what's required, of course. Jim From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 17:39:50 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04877; Tue, 9 Nov 93 16:44:05 EST Received: from smaug.src.honeywell.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04872; Tue, 9 Nov 93 16:43:55 EST Received: by smaug.src.honeywell.com (4.1/SMI-3.2) id AA21528; Tue, 9 Nov 93 15:43:14 CST From: iacovou@src.honeywell.com (Danny Iacovou) Message-Id: <9311092143.AA21528@smaug.src.honeywell.com> Subject: Re: A spec for showing language in MIME headers To: de19@umail.umd.edu (Dana S Emery) Date: Tue, 9 Nov 1993 15:43:13 -0600 (CST) Cc: ietf-822@dimacs.rutgers.edu In-Reply-To: from "Dana S Emery" at Nov 9, 93 03:59:45 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1406 Dana S Emery writes: > > rhys> Show me someone who wants to communicate daily in 16th > rhys> century English or Japanese in e-mail, and you may > rhys> convince me. > > You may have intended that as a rhetorical Q, but I am > interpreting it as a challange. >:-)> > > Linguistic scholars, Classics Scholars, and Early Music > scholars/enthusiasts are 3 categories that come to mind > immediatly, all employ mail-lists and/or newsgroups and > are doing research which commands respect, if not some > degree of support. I have to agree with Dana. Basically what it all boils down to is that a small number of people will complain if they can't communicate in 16th century English via e-mail. However, in the long run, a lot of people will be very pleased to know that they can. Its the second group that we should look out for. Just as an aside, the UofMn English Dept. already offers courses that deal with various markup languages and how they can be used in terms of preservation of texts, production of new texts, etc etc. The people involved with that work would love to be able to send e-mail in 16th century English to each other. I'd be willing to bet money on that. -------------------------------------------------------------------------------- Neophytos Iacovou Honeywell Systems & Research Center iacovou@src.honeywell.com Minneapolis, Mn, 55418 From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 18:34:43 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05175; Tue, 9 Nov 93 17:25:43 EST Received: from thumper.bellcore.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05171; Tue, 9 Nov 93 17:25:42 EST Received: from guppylake.bellcore.com (guppylake.bellcore.com [128.96.40.15]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id RAA18594; Tue, 9 Nov 1993 17:24:35 -0500 Received: by guppylake.bellcore.com (4.1/4.7) id for hansen@pegasus.att.com; Mon, 8 Nov 93 20:43:07 EST 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, 8 Nov 1993 20:43:06 -0500 (EST) Message-Id: Date: Mon, 8 Nov 1993 20:43:06 -0500 (EST) From: Nathaniel Borenstein To: ietf-822@dimacs.rutgers.edu, hansen@pegasus.att.com (t.l.hansen) Subject: Re: Text/enriched ambiguity In-Reply-To: Message from "hansen@pegasus.att.com (t.l.hansen)" dated "2 Nov 1993 14:36 EST" References: I find Tony's argument quite compelling: > Doing it the other way leads to the same mess that had. (Even if > it was only 20 lines of code. :-) ) Frankly, I don't think is worth the bother of an extended debate. Is there anyone who thinks the current situation is unlivable, a "show-stopper"? If you feel that way, if the choice was between leaving it as-is or nuking the construct altogether, which would you prefer? Personally, I'm happy enough with the spec as-is, and rather tired of thinking about it... - - Nathaniel From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 18:10:13 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05112; Tue, 9 Nov 93 17:14:11 EST Received: from ics.uci.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05108; Tue, 9 Nov 93 17:14:09 EST Received: from nma.com by q2.ics.uci.edu id ae18807; 9 Nov 93 14:13 PST Received: from localhost by odin.nma.com id aa29349; 9 Nov 93 13:48 PST To: MIME Subject: Re: comment on draft-vandreuil-mime-sig-00.txt Reply-To: Stef@nma.com From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 09 Nov 1993 13:48:11 -0800 Message-Id: <29347.752881691@odin.nma.com> Sender: stef@nma.com it seems to me that we should also consider some name other than "signature", as in application/signature or text/signature. I feel that a signature is more often more than the junk pe9opl eput at the end of their messages, as a footer, or trailer. It is, after all, contact info, or business card info, not a signature. Can we dredge up a better term with will not collide with so many semanic loading of the word "signature"? As Marshall says "In general, naming is a problem!"...\Stef From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 18:39:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05652; Tue, 9 Nov 93 18:09:17 EST Received: from alpha.Xerox.COM by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05648; Tue, 9 Nov 93 18:09:16 EST Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <12150(2)>; Tue, 9 Nov 1993 15:08:57 PST Received: by golden.parc.xerox.com id <2795>; Tue, 9 Nov 1993 15:08:52 -0800 To: iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu In-Reply-To: Keith Moore's message of Sun, 7 Nov 1993 17:49:51 -0800 <9311080149.AA11656@thud.cs.utk.edu> Subject: Re: Web and Mail integration: a few key connections. From: Larry Masinter Sender: Larry Masinter Fake-Sender: masinter@parc.xerox.com Message-Id: <93Nov9.150852pst.2795@golden.parc.xerox.com> Date: Tue, 9 Nov 1993 15:08:44 PST On web and mail integration: Perhaps we could extend what Mime is using for 'content-type' to a more general 'resource type'; some kinds of resources are actual files with a given format, but other things that we want are URLs for interactive services which will have a type of 'telnet/3270' vs 'telnet/vt220', or multicast audio and video channels. I was puzzling how to 'type' these things as long as they were supposed to fit within 'content-type', until I realized that content-type could be considered just a subset of a more general case. From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 19:09:36 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05833; Tue, 9 Nov 93 18:34:34 EST Received: from pandora.sf.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA05829; Tue, 9 Nov 93 18:34:32 EST From: mitra@path.net (Mitra) Date: Tue, 9 Nov 1993 15:34:17 PDT In-Reply-To: Larry Masinter "Re: Web and Mail integration: a few key connections." (Nov 9, 3:08pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: masinter@parc.xerox.com, iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu Subject: Re: Web and Mail integration: a few key connections. Message-Id: <9311091534.aa12932@pandora.sf.ca.us> I believe that some of these sorts of thgings (e.g. telnet) are registered by the gopehr folks - Mitra From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 20:09:36 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06199; Tue, 9 Nov 93 19:44:43 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06195; Tue, 9 Nov 93 19:44:38 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Wed, 10 Nov 93 10:43:38 +1000 Date: Wed, 10 Nov 93 10:43:36 EST From: rhys@cs.uq.oz.au Message-Id: <9311100043.AA16021@client> To: hansen@pegasus.att.com, ietf-822@dimacs.rutgers.edu, nsb@thumper.bellcore.com Subject: Re: Text/enriched ambiguity >I find Tony's argument quite compelling: > >> Doing it the other way leads to the same mess that had. (Even if >> it was only 20 lines of code. :-) ) > >Frankly, I don't think is worth the bother of an extended >debate. Is there anyone who thinks the current situation is unlivable, >a "show-stopper"? If you feel that way, if the choice was between >leaving it as-is or nuking the construct altogether, which would you >prefer? Leave it as is. I'm happy with it. Maybe just a couple of words about whether commands inside nest or whether the parameters end at the (this later one is my preferred option). Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 19:39:39 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06032; Tue, 9 Nov 93 19:19:26 EST Received: from necom830.cc.titech.ac.jp by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06028; Tue, 9 Nov 93 19:19:22 EST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 10 Nov 93 09:13:58 +0859 From: Masataka Ohta Return-Path: Message-Id: <9311100014.AA06959@necom830.cc.titech.ac.jp> Subject: Re: A spec for showing language in MIME headers To: iacovou@src.honeywell.com (Danny Iacovou) Date: Wed, 10 Nov 93 9:13:55 JST Cc: de19@umail.umd.edu, ietf-822@dimacs.rutgers.edu In-Reply-To: <9311092143.AA21528@smaug.src.honeywell.com>; from "Danny Iacovou" at Nov 9, 93 3:43 pm X-Mailer: ELM [version 2.3 PL11] > Basically what it all boils down to is that a small number of people will > complain if they can't communicate in 16th century English via e-mail. They can, of course. All they need is an appropriate character set. They don't need any language tag for their communication. Masataka Ohta From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 20:39:42 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06312; Tue, 9 Nov 93 20:04:18 EST Received: from THUD.CS.UTK.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06308; Tue, 9 Nov 93 20:04:16 EST Received: from LOCALHOST by thud.cs.utk.edu with SMTP (5.61+IDA+UTK-930922/2.7c-UTK) id AA17803; Tue, 9 Nov 93 20:03:25 -0500 Message-Id: <9311100103.AA17803@thud.cs.utk.edu> From: Keith Moore To: Larry Masinter Cc: iiir@merit.edu, uri@bunyip.com, www-talk@nxoc01.cern.ch, ietf-822@dimacs.rutgers.edu, moore@cs.utk.edu Subject: Re: Web and Mail integration: a few key connections. In-Reply-To: Your message of "Tue, 09 Nov 1993 15:08:44 PST." <93Nov9.150852pst.2795@golden.parc.xerox.com> Date: Tue, 09 Nov 1993 20:03:14 -0500 Sender: moore@cs.utk.edu > On web and mail integration: > > Perhaps we could extend what Mime is using for 'content-type' to a > more general 'resource type'; some kinds of resources are actual files > with a given format, but other things that we want are URLs for > interactive services which will have a type of 'telnet/3270' vs > 'telnet/vt220', or multicast audio and video channels. I think that's appropriate, so long as we know how to draw the line between the MIME types that can be carried in mail and those that don't. Maybe the distinction (at the top-level) is interactive vs. non-interactive. So: interactive-text/telnet; TERM=vt220 interactive-text/tn3270 (this really is a different protocol) interactive-text/rlogin interactive-text/x25pad interactive-text/lat interactive-text/cterm interactive-text/dialup; PN="+1.615.555.1212" interactive-audio/vat interactive-video/nv (but the names should describe protocols, not specific tools) Remember, the main reason for the top-level MIME type is to give gateways an clue as to whether than discard, convert, or retain the content. If gateways are willing to do protocol translations across network boundaries the distinction might somehow still be useful. Keith From owner-ietf-822@dimacs.rutgers.edu Tue Nov 9 21:09:42 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06409; Tue, 9 Nov 93 20:23:10 EST Received: from uqcspe.cs.uq.oz.au by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06405; Tue, 9 Nov 93 20:23:04 EST Received: from everest.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Wed, 10 Nov 93 11:23:01 +1000 Date: Wed, 10 Nov 93 11:23:00 EST From: rhys@cs.uq.oz.au Message-Id: <9311100123.AA17370@client> To: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headers > Just as an aside, the UofMn English Dept. already offers courses that > deal with various markup languages and how they can be used in terms of > preservation of texts, production of new texts, etc etc. The people involved > with that work would love to be able to send e-mail in 16th century English > to each other. I'd be willing to bet money on that. The question as I see it has become: are they going to use their domain-specific markup languages to send text, or do they want to send it in text/plain? Nothing is stopping them defining a "text/old-english" content type for their particular markup styles, in which case the language information will be internal to the document, rather than sent in the Content-Language header. The Content-Language header was initially presented as a way to choose the best body part to display to the user, the best fonts to use, or the best speech synthesis unit to use for sight-impaired people. If we start getting into date stamping and linguistic information, our MIME software is going to be much more complex, for something that already has existing domain-specific solutions that the IETF parties aren't experts in. If on the other hand, ISO saw fit to register an "eno" (English Old) language tag, then text/plain could be used. The point is that it becomes ISO's problem to define exactly what range of dates "eno" (and even "en") actually means: IETF is off the hook. Masataka seems worried that the "en" of today may bear very little resemblance to the "en" of 200 years from now, and so old messages in archives may be interpreted as the future "en" rather than the "old" one. He also seems worried that something like "ru-su" becoming "ru-ru" overnight may cause the net to disintegrate. I'm unconvinced at the moment that this is a problem that the IETF needs to solve. Usage of tags, just as usage of languages, will evolve over time, and it is not up to the IETF to say how they can evolve. I _would_ support making the country code into something that should be used only if it is absolutely necessary to disambiguate different usages of the same language. e.g. French and French-Canadian which have different capitalisation rules I believe. Hence, Russian would be "ru" and English would be "en", no matter what country, unless it is absolutely necessary that the recipient hear it with a Ukrainian ("ru-ua") or an Australian ("en-au") accent respectively. Cheers, Rhys. From owner-ietf-822@dimacs.rutgers.edu Wed Nov 10 00:09:38 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11072; Tue, 9 Nov 93 23:40:03 EST Received: from umail.umd.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11068; Tue, 9 Nov 93 23:40:02 EST Received: by umail.UMD.EDU (5.57/Ultrix3.0-C) id AA13906; Tue, 9 Nov 93 23:39:59 -0500 Date: Tue, 9 Nov 93 23:40:00 -0500 From: Dana S Emery To: ietf-822@dimacs.rutgers.edu Subject: Re: A spec for showing language in MIME headers Message-Id: In-Reply-To: Your message <9311100123.AA17370@client> of Wed, 10 Nov 93 11:23:00 EST Content-Type: TEXT/plain; charset=US-ASCII > The Content-Language header was initially presented as a > way to choose the best body part to display to the user, > the best fonts to use, or the best speech synthesis unit > to use for sight-impaired people. Excellent reminder. Unfortunatly, it is not simple or (IMHO) desirable to attempt to define a system to conflate both the audible and visual hints into one header. Far better to separate them into similar but independant headers. Content-Audible-Languge Content-Writing-System might do. giving us (for documents with uniform content): Content-Audible-Languge: Content-Writing-System: Content-Audible-Languge: Content-Writing-System: Content-Audible-Languge: Content-Writing-System: and for marked up body content (by whatever means) Content-Audible-Languge: Mixed Content-Writing-System: Content-Audible-Languge: Mixed Content-Writing-System: Mixed to give fair warning of poly-content. I suspect that there is some reference work known to linquists which would serve our needs better than 639 for values, but I am ignorant of it, If no one here can come up with anything in the next coupla days I will take up the matter with librarians and professori. Clearly the utility of the audible hints will be limited to availability of support software, so if any of you is involved in that area perhaps some references could be turned up that way. From owner-ietf-822@dimacs.rutgers.edu Wed Nov 10 00:39:41 1993 Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11296; Wed, 10 Nov 93 00:17:02 EST Received: from pandora.sf.ca.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11292; Wed, 10 Nov 93 00:17:01 EST From: mitra@path.net (Mitra) Date: Tue, 9 Nov 1993 21:16:25 PDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: ietf-