informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/SURFPUNK/surf0069.txt
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

467 lines
18 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Date: Thu, 1 Apr 93 20:04:39 PST
Reply-To: <surfpunk@osc.versant.com>
Return-Path: <cocot@osc.versant.com>
Message-ID: <surfpunk-0069@SURFPUNK.Technical.Journal>
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" <nsb@bellcore.com>
To: Mark Linimon <linimon@lonesome.com>
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 <surfpunk@osc.versant.com>, subscription requests
to <surfpunk-request@osc.versant.com>. MIME encouraged.
Xanalogical archive access soon. Beam us up, Borenstein!
________________________________________________________________________
________________________________________________________________________
Reference in New Issue View Git Blame Copy Permalink