IPP Mail Archive: Re: IPP> RFC 3251 - Electicity over IP

IPP Mail Archive: Re: IPP> RFC 3251 - Electicity over IP

Re: IPP> RFC 3251 - Electicity over IP

From: Robert Herriot (bob@herriot.com)
Date: Mon Apr 01 2002 - 17:54:55 EST

  • Next message: Hastings, Tom N: "RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15"

    So perhaps we should have sent in some IPP specs as April fools specs -- the
    joke being that they were real.

    Bob

    ----- Original Message -----
    From: "Carl" <carl@manros.com>
    To: "McDonald, Ira" <imcdonald@sharplabs.com>; <ipp@pwg.org>
    Sent: Monday, April 01, 2002 2:26 PM
    Subject: RE: IPP> RFC 3251 - Electicity over IP

    > In case you don't know, April 1 RFCs has the highest priority in the RFC
    > editor's queue.
    >
    > Carl-Uno
    >
    > > -----Original Message-----
    > > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald,
    > > Ira
    > > Sent: Monday, April 01, 2002 10:30 AM
    > > To: 'ipp@pwg.org'
    > > Subject: IPP> RFC 3251 - Electicity over IP
    > >
    > >
    > > Hi folks,
    > >
    > > I couldn't resist sending on this "light" reading:
    > >
    > > RFC 3251 "Electricity over IP"
    > > ftp://ftp.isi.edu/in-notes/rfc3251.txt
    > >
    > > RFC 3252 "Binary Lexical Octet Ad-hoc Transport (BLOAT)"
    > > ftp://ftp.isi.edu/in-notes/rfc3252.txt
    > >
    > > Cheers,
    > > - Ira McDonald
    > > High North Inc
    > >
    > > ------------------------------
    > > [from RFC 3251]
    > > Abstract
    > >
    > > Mostly Pointless Lamp Switching (MPLampS) is an architecture for
    > > carrying electricity over IP (with an MPLS control plane). According
    > > to our marketing department, MPLampS has the potential to
    > > dramatically lower the price, ease the distribution and usage, and
    > > improve the manageability of delivering electricity. This document
    > > is motivated by such work as SONET/SDH over IP/MPLS (with apologies
    > > to the authors). Readers of the previous work have been observed
    > > scratching their heads and muttering, "What next?". This document
    > > answers that question.
    > >
    > > This document has also been written as a public service. The "Sub-
    > > IP" area has been formed to give equal opportunity to those working
    > > on technologies outside of traditional IP networking to write
    > > complicated IETF documents. There are possibly many who are
    > > wondering how to exploit this opportunity and attain high visibility.
    > > Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS
    > > control for random technologies) as highly amenable for producing a
    > > countless number of unimplementable documents. This document
    > > illustrates the key ingredients that go into producing any "foo-
    > > over-MPLS" document and may be used as a template for all such work.
    > >
    > > [from RFC 3252]
    > > Abstract
    > >
    > > This document defines a reformulation of IP and two transport layer
    > > protocols (TCP and UDP) as XML applications.
    > >
    > > 1. Introduction
    > >
    > > 1.1. Overview
    > >
    > > This document describes the Binary Lexical Octet Ad-hoc Transport
    > > (BLOAT): a reformulation of a widely-deployed network-layer protocol
    > > (IP [RFC791]), and two associated transport layer protocols (TCP
    > > [RFC793] and UDP [RFC768]) as XML [XML] applications. It also
    > > describes methods for transporting BLOAT over Ethernet and IEEE 802
    > > networks as well as encapsulating BLOAT in IP for gatewaying BLOAT
    > > across the public Internet.
    > >
    > > 1.2. Motivation
    > >
    > > The wild popularity of XML as a basis for application-level protocols
    > > such as the Blocks Extensible Exchange Protocol [RFC3080], the Simple
    > > Object Access Protocol [SOAP], and Jabber [JABBER] prompted
    > > investigation into the possibility of extending the use of XML in the
    > > protocol stack. Using XML at both the transport and network layer in
    > > addition to the application layer would provide for an amazing amount
    > > of power and flexibility while removing dependencies on proprietary
    > > and hard-to-understand binary protocols. This protocol unification
    > > would also allow applications to use a single XML parser for all
    > > aspects of their operation, eliminating developer time spent figuring
    > > out the intricacies of each new protocol, and moving the hard work of
    > > parsing to the XML toolset. The use of XML also mitigates concerns
    > > over "network vs. host" byte ordering which is at the root of many
    > > network application bugs.
    > >
    >
    >
    >
    >



    This archive was generated by hypermail 2b29 : Mon Apr 01 2002 - 17:52:25 EST