Modified registration of APPLICATION/IP

[Donald E. Eastlake 3rd]

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 at torque.pothole.com

   Intended usage: LIMITED USE

   Author/Change controller: IETF





































D. Eastlake 3rd                                                 [Page 8]


------- End of Forwarded Message