Based on Last Call comments received, I have just posted a new version
of draft-eastlake-ip-mime. Here is the revised MIME type
registration...
MIME media type name: APPLICATION
MIME subtype name: IP
Required parameters: version
version=n
This parameter exposes the IP Version number [RFC 791] in the
MIME Content-Type.
Optional parameters: dilation, address
dilation=nnn
Typically IP packets will be MIME labeled for transmission over
email or other application level protocols. Such transmission
is normally slower than lower level network protocols. While
this is not much of a concern if a packet is just being
communicated for analysis, if such transmission is used to
establish connectivity, the sender of a datagram may wish to
advise the recipient of the estimated time dilation factor.
For example, if datagrams typically take around a second and
occasionally up to ten seconds end-to-end but it is more like a
minute and occasionally up to ten minutes if they are MIME
encoded in email, a "dilation=60" parameter would be
reasonable.
Note: Although IP and TCP are defined as timing independent
protocols, many implementations actually have timeouts built
in. In some cases, an effective technique to defeat these
timeouts is to repeatedly resend the last packet received.
This is, if a MIME encoded TCP packet is being sent from Host A
to Host B in the figure above where the applications are
gatewaying the packets to the real IP stack, repeated
transmission of this packet by the application on Host B to the
stack may stave off timeouts. Similarly, the repeated
transmission to the real IP stack on Host A of the last reply
TCP packet may stave off timeouts there.
address=xxx
Full, if slow, IP connectivity via an application level
protocol such as SMTP [RFC 2821, 2822] might require that
routing, tunneling, and/or interface entries be installed at
each end. Routing entries would be best created or updated by
routing protocol messages and the establishment of tunnels is
beyond the scope of this MIME type. However, the address=
parameter enables the sender to optionally indicate an IP
address for itself. This may only be useful in cases where the
sender knows an address that is available for itself in the
recipient's addressing environment. It can be viewed as a
replacement for ARP [RFC 826] on the possible path to the
source of the APPLICATION/IP object via the same application
level protocol. (A receiver of such an APPLICATION/IP object
with an address= parameter might reasonably require that it be
authenticated as meeting their policy as to from whom they
would accept such information. For example, they could ignore
address= parameters unless the APPLICATION/IP object was
wrapped in an acceptable MULTIPART/SIGNED [RFC 1847]
authentication, although that implies some trust relationship
between the parties.)
Examples:
address="10.100.1.10"
address="1080:0:0:0:8:800:200C:4171"
Encoding considerations: Because of the binary nature of the body,
BASE64 transfer encoding should normally be used.
Security considerations: Care should be taken under any circumstance
where APPLCIATION/IP content can be treated as a "live" packet.
MULTIPART/ENCRYPTED and MULTIPART/SIGNED [RFC 1847] may be used
to further disguise and/or authenticate MIME packaged IP
traffic.
Interoperability considerations: See [draft-eastlake-ip-mime-*.txt].
MULTIPART/MIXED [RFC 2046] may be used to package multiple IP
datagrams together.
Published specification: See [draft-eastlake-ip-mime-*.txt].
Applications which use this media type: Not yet in use. See also
[RFC 3093].
Additional information: (none)
Person & email address to contact for further information:
Donald E. Eastlake 3rd, dee3(a)torque.pothole.com
Intended usage: LIMITED USE
Author/Change controller: IETF
D. Eastlake 3rd [Page 8]
------- End of Forwarded Message
