connecting RFC April Fool dots

[Lloyd Wood <l.wood at eim.surrey.ac.uk>]

From:

http://www.normos.org/ietf/rfc/rfc3093.txt

   We got this idea from the increasing number of applications that use
   HTTP specifically because it can bypass Firewall barriers.

and not from reading the referenced

http://ring.gr.jp/pub/doc/internet-drafts/draft-eastlake-ip-mime-04.txt

?

   This
   piecemeal deployment of specific applications is not an efficient way
   to meet the challenge to innovation created by Firewalls.  We decided
   to develop a process by which TCP/IP itself is carried over HTTP.

Ah, the theoretical world of the Harvard academic. Pity I missed last
call. Mind you, I don't know how long that this work was stuck in the
RFC Editor's queue; given the current state of the art (and the
queue), it would not be unduly generous to the authors (if not to the
Editor) to assume several years.

Some state of the art:

http://www.nocrew.org/software/httptunnel.html
http://www.ntk.net/index.cgi?back=2000/now1124.txt&line=164#l
http://sureshot.virtualave.net/tcptunnel/

There's scope for writing a draft that just clearly defines the
mediatype (a la RFC3023); I'd suggest calling the mimetypes e.g.
application/IP-4-datagram and application/IP-6-datagram. This improves
implementation interoperability, as it's then so much easier to
determine that e.g. IPv6 (-6) and core-based-tree multicast (-7) just
aren't accepted or supported; pretending they are then takes more of a
commitment on the part of the implementers, who aren't going
to bother anyway. Especially with multicast.

There's a clear advantage in going for 7-bit encoding in that it gives
you reliable and much simpler SMTP-HTTP interaction, as you switch to
email if you don't have port 80 access to the big wide world, or
transparently pass between web proxy servers and mailservers to pass
over multiple firewalls en route to your destination (e.g. your friend
at his hot-but-not-capitalist startup in Zhejiang, inside the Great
Firewall of China), without having to decode and encode the payload at
each step.

http://www.ntk.net/index.cgi?back=2000/now0310.txt&line=151#l
http://detached.net/mailtunnel/

Since TCP/IP packets are likely to be small (the good old Ethernet
MTU), 7-bit overhead is not an issue. However, it would be interesting
to develop an analogue of path MTU discovery, decreasing fragmentation
throughout. If your FEP driver is on your computer rather than in a
proxy on a local subnet that you're tunnelling your packets to,
there's no need to stick to Ethernet MTU size for the tunnelled
packets. The maximum message size mail gateways will support becomes a
more important constraint. (of course, there's a need for
application/IP-4-fragment etc. too, for when this process fails.)

Defining how discovery and routing will be accomplished in this
virtual overlay web-proxy/mail-gateway network strikes me interesting,
as does increasing performance by implementing email spoofing to break
the overall end-to-end loop into smaller loops to increase
performance - necessary given TCP's tendency to timeout.

This should be fertile ground for topics for PhD students.
We still have PhD students, yes?

We're entering a recession, right? Ostermann was wrong, right?
http://www.acm.org/sigcomm/sigcomm98/Ostermann/slide2.html

We _do_ need standards in this area.

L.

first suggested HDLC over HTTP several years ago, as a sensible
and deployable alternative to SCSI over IP.

<L.Wood at surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>