Date: Thu, 1 Apr 93 20:04:39 PST Reply-To: Return-Path: Message-ID: Mime-Version: 1.0 Content-Type: text/plain From: surfpunk@osc.versant.com (znggre-genafcbeg/fragvrag-yvsr-sbez) To: surfpunk@osc.versant.com (SURFPUNK Technical Journal) Subject: [surfpunk-0069] 1APR: two new RFCs: IETF SOBs, MIME Content-Types... In what Dr Protocol calls the "ultimate of gentility", the documents used to define standards on the internet are humbly called Requests For Comment (RFC). Here are two new ones today: RFC 1438 IETF SOBs 1 April 1993 RFC 1437 MIME Content-Types for a New Medium 1 April 1993 Thanks to jpd@moo.acns.nwu.edu (J. Phillip Draughon). ... strick ________________________________________________________________________ ________________________________________________________________________ Network Working Group L. Chapin Request for Comments: 1438 BBN C. Huitema INRIA 1 April 1993 Internet Engineering Task Force Statements Of Boredom (SOBs) Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Discussion The current IETF process has two types of RFCs: standards track documents and other RFCs (e.g., informational, experimental, FYIs). The intent of the standards track documents is clear, and culminates in an official Internet Standard. Informational RFCs can be published on a less formal basis, subject to the reasonable constraints of the RFC Editor. Informational RFCs are not subject to peer review and carry no significance whatsoever within the IETF process. The IETF currently has no mechanism or means of publishing documents that express its deep concern about something important, but otherwise contain absolutely no useful information whatsoever. This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). The SOB process is similar to that of the normal standards track. The SOB is submitted to the IAB, the IRSG, the IESG, the SOB Editor (Morpheus), and the Academie Francais for review, analysis, reproduction in triplicate, translation into ASN.1, and distribution to Internet insomniacs. However, once everyone has approved the document by falling asleep over it, the process ends and the document is discarded. The resulting vacuum is viewed as having the technical approval of the IETF, but it is not, and cannot become, an official Internet Standard. Chapin & Huitema [Page 1] RFC 1438 IETF SOBs 1 April 1993 References [1] Internet Activities Board, "The Internet Standards Process", RFC 1310, IAB, March 1992. [2] Postel, J., Editor, "IAB OFFICIAL PROTOCOL STANDARDS", RFC 1410, IAB, March 1993. Security Considerations Security issues are not discussed in this memo, but then again, no other issues of any importance are discussed in this memo either. Authors' Addresses A. Lyman Chapin Bolt, Beranek & Newman Mail Stop 20/5b 150 Cambridge Park Drive Cambridge, MA 02140 USA Phone: 1 617 873 3133 EMail: Lyman@BBN.COM Christian Huitema INRIA, Sophia-Antipolis 2004 Route des Lucioles BP 109 F-06561 Valbonne Cedex France Phone: +33 93 65 77 15 EMail: Christian.Huitema@MIRSA.INRIA.FR Chapin & Huitema [Page 2] ________________________________________________________________________ ________________________________________________________________________ Network Working Group N. Borenstein Request for Comments: 1437 Bellcore M. Linimon Lonesome Dove Computing Services 1 April 1993 The Extension of MIME Content-Types to a New Medium Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the matter-transport/sentient-life-form type. The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings. Other informally proposed subtypes, such as "non-sentient-life-form", "non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo. The matter-transport/sentient-life-form MIME type In order to promote the wider interoperability of life-bearing email, this document defines a new MIME content-type, "matter-transport", and for an initial subtype, "sentient-life-form". This subtype was designed to meet the following criteria: 1. The syntax must be extremely simple to parse, to minimize the risk of accidental death due to misinterpretation of the standard. 2. The data format must be extremely robust, with redundancy to ensure that individual life forms will survive and be reconstituted in such a form as to be nearly indistinguishable from their initial state, no matter how many bizarre email gateways are encountered in transit. 3. The syntax must be extensible to allow for the description of all yet-undiscovered aspects of life forms which will be required Borenstein & Linimon [Page 1] RFC 1437 MIME Content-Types for a New Medium 1 April 1993 for the transport of non-human species (e.g. dolphins, Klingons, or politicians). 4. The syntax must be compatible with SGML, so that with an appropriate DTD (Document Type Definition -- the standard mechanism for defining a document type using SGML), a general SGML parser could be written to parse the data structure and produce directives to a lifeform-reconstitution mechanism. However, despite this compatibility, the syntax will most likely be far simpler than that of full SGML (so that no SGML knowledge is required in order to implement it), since it is anticipated that the full complexities of SGML will not be necessary for the description of even arbitrarily complex organic life forms. The syntax of the new content-type is very simple, and indeed makes considerable sacrifice of efficiency in the interest of simplicity. It is assumed to describe a three-dimensional rectangular solid, with the height, width, and depth (calibrated in centimeters) specified as parameters on the content-type line. (In general, this should be a cube that completely contains the life form being transported; but, where high bandwidth is not available, a somewhat smaller cube can be used, provided that facilities are known to be available at the recipient's end to administer the medical first aid that could be necessary if an individual is reconstituted sans some of its extremities.) A fourth parameter gives the resolution of the matter scan, calibrated in Angstroms. Thus, the following Content-type value: Content-type: matter-transport/sentient-life-form; height = 200; width = 60; depth=60; resolution=10 implies that the cube being described is 60 cm by 60 cm by 200 cm, and is described to a resolution of 10 Angstroms. The resolution gives the quantization unit, and therefore determines the quality of the reproduction. The data stream itself then consists of a readout of the molecule found at each location, using the given resolution. If the resolution is high enough that more than one molecule is found in a given location, the molecule whose nucleus is closest to the center of the cube is used. Each molecule is described by its molecular formula, rendered in ASCII for maximum readability if matter-transport mail is inadvertently delivered to a human recipient and displayed on a terminal screen. Each molecule is followed by a space (ASCII 32) to separate it from the subsequent molecule description. Extremely long molecules may require the use of a content-transfer-encoding such as quoted-printable, to ensure that line-wrapping mail systems do not, for example, cause the unintended breakdown of complex proteins into their constituent elements. Borenstein & Linimon [Page 2] RFC 1437 MIME Content-Types for a New Medium 1 April 1993 The following is a message that gives a somewhat simplified rendition of a well-known American politician, starting from the top: From: "Nathaniel S. Borenstein" To: Mark Linimon Subject: Think hard before reconstructing Content-description: Dan Quayle, low-res version Content-type: matter-transport/sentient-life-form height = 200; width = 60; depth=60; resolution=100000 Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 NO2 Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Fe Obviously, a real politician's skull is more complex than pure iron, as is its interior, but this simplified example should give the general flavor of the protocol. (A caveat, however, in the reconstitution of Vice-Presidents of the United States: allegedly, some of the matter-reconstitution schemes currently under development are reputed to perform less than optimally while trying to reconstitute areas of relatively high vacuum; for instance, their skulls. A recommended acceptance test might be to experiment with subjects whose skulls are only at partial vacuum, such as Vice-Presidents of Marketing.) MHS (X.400) Gateway Considerations The proper behavior of a MIME/MHS gateway with regard to the transmission of complex multimedia messages is a topic of ongoing investigation under the auspices of the IETF. The addition of matter transport should not significantly complicate that effort, as it is already necessary to specify gateway behavior for MIME types that have no X.400 equivalents, and matter transport is simply another Borenstein & Linimon [Page 3] RFC 1437 MIME Content-Types for a New Medium 1 April 1993 such untranslatable type. However, real-world X.400 gateways might be considered to significantly increase the hazard that mail containing a human being will be rejected with a message so cryptic that the recipient deletes it without ever realizing that an embedded human being is enclosed. For this reason, it is recommended that the subject of matter transport be explicitly marked "for further study" in the next generation of the X.400 specification, X.400-1996. This will give the community ample time to define a more complete specification for matter transport as part of X.400-2000, and possibly even a readily- implementable specification as part of X.400-2004, although some will no doubt argue that this would be too strong a break with tradition. Implementation Considerations The user is cautioned against passing MIME transporter messages through computers equipped with the NFS file system. A no-file space error caused one of the laboratory rats on our prototype system to be truncated to a zero-length file. Unfortunately we had neglected to mount a scratch rat. (We have decided to permanently retain the empty filename in his honor). Byte swapping problems on other storage systems can be similarly annoying, but should not be a problem if network byte order is always maintained ocrrcelty. Despite the authors' belief in the robustness of the protocol, passage of email through certain systems seems to result in the sentient-life-form arriving at its destination upside down, resulting in an annoying "thud". The cause is still under investigation. Interoperation with matter-transporters using polar coordinate systems is discouraged, due to round-off and other algorithmic errors in certain ubiquitous floating-point implementations, leading to results which are best discreetly described as "disappointing." Similarly, off-by-one errors should be avoided. Widespread adoption of this protocol may lead to an increase in user demand for reliable backup systems. More importantly, for the first time management may be motivated to adequately fund such systems when they discover the possibility that proper email backup may confer upon them virtual immortality. (On the other hand, implementors should seriously consider the desirability of making their managers immortal.) Borenstein & Linimon [Page 4] RFC 1437 MIME Content-Types for a New Medium 1 April 1993 An additional concern reflects the fact that, prior to the introduction of this content-type, duplicate mail delivery was a relatively minor nuisance. With the mail extensions described in this document, however, comes the possibility that duplicate mail delivery will leave a user with, for example, multiple spouses or mothers-in-law. The relative weights of the desire to avoid duplicate delivery and the desire to avoid lost mail may change accordingly. Security Considerations Security considerations are not discussed in this memo. However, law enforcement officials might wish to consider the possibility that this mechanism could be used by criminals, either to escape extradition by mailing themselves outside of a legal jurisdiction, or to outwait the statute of limitations by mailing themselves through complex mail routes with long delays. (One supposes that they could also look on the bright side, and consider MIME as a possible approach to solving the long-standing problem of prison overcrowding.) Authors The authors of this document may be reconstituted by feeding the following data to an Internet-connected MIME reader: Content-type: multipart/mixed; boundary=NextAuthor --NextAuthor Content-type: message/external-body; access-type=anon-ftp; site=thumper.bellcore.com; directory=pub/nsb; name=nsb.flesh Content-Description: Nathaniel Borenstein Content-type: matter-transport/sentient-life-form height = 200; width = 60; depth=60; resolution=100000 --NextAuthor Content-type: message/external-body; access-type=anon-ftp; site=thumper.bellcore.com; directory=pub/nsb; name=linimon.flesh Content-Description: Mark Linimon Content-type: matter-transport/sentient-life-form height = 200; width = 60; depth=60; resolution=100000 --NextAuthor-- Borenstein & Linimon [Page 5] RFC 1437 MIME Content-Types for a New Medium 1 April 1993 Authors' Addresses Nathaniel Borenstein Bellcore Room MRE 2D-296 445 South Street Morristown, NJ 07962-1910 Phone: (201) 829-4270 EMail: nsb@bellcore.com Mark Linimon Lonesome Dove Computing Services P.O. Box 20291 Roanoke, VA 24018 Phone: (703) 776-1004 EMail: linimon@LONESOME.COM Borenstein & Linimon [Page 6] ________________________________________________________________________ ________________________________________________________________________ The SURFPUNK Technical Journal is a dangerous multinational hacker zine originating near BARRNET in the fashionable western arm of the northern California matrix. Quantum Californians appear in one of two states, spin surf or spin punk. Undetected, we are both, or might be neither. ________________________________________________________________________ Send postings to , subscription requests to . MIME encouraged. Xanalogical archive access soon. Beam us up, Borenstein! ________________________________________________________________________ ________________________________________________________________________