[e2e] end of interest -- BP metadata / binary vs text

[L.Wood@surrey.ac.uk]

BEEP gives us MIME, but is inherently rigidly transactional
(RFC3080 section 2.1.1), which puts it as a disadvantage
for long-delay links. HTTP PUTs can be entirely one-way...
never mind BEEP's profile uri's. (I do find the HTTP specs far
easier to read and follow.)

HTTP, BEEP and the Bundle Protocol aren't network protocols...
really session layers (well, the BP's always compared to email,
and an email message can be thought of as a session?). Doing
sessions as text helps for debugging and modifications.

L.

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



-----Original Message-----
From: Jon Crowcroft [mailto:Jon.Crowcroft at cl.cam.ac.uk]
Sent: Sat 2008-05-10 17:19
To: Rajesh Krishnan
Cc: Wood L Dr (Electronic Eng); craig at aland.bbn.com; day at std.com; end2end-interest at postel.org; Jon.Crowcroft at cl.cam.ac.uk
Subject: Re: [e2e] end of interest -- BP metadata / binary vs text 
 
yep

two alternates to the BP stuff suggest themselves...

1. Blocks/BEEP:
http://www.ietf.org/rfc/rfc3080.txt
if you are http mindfuk
and
2. some of the data naming/framing ideas in Reliable Multicast
http://portal.acm.org/citation.cfm?id=290808
if you are more rad

In missive <1210432515.7973.171.camel at localhost.localdomain>, Rajesh Krishnan typed:

 >>Lloyd,
 >>
 >>Yes, we discussed this on dtn-interest.   What you say regarding text
 >>being successful has been true of many application protocols, while
 >>network/lower layer protocols favor a binary form. I do not have a
 >>preference for either -- text is convenient until there is sizeable
 >>metadata that is intrinsically binary (index shot thumbnail of a movie
 >>scene).
 >>
 >>I view BP or its successor as having the potential for being a
 >>storage-aware network layer protocol rather than remain at the
 >>session/application layer of a TCP/IP network.   Rose-colored 
 >>glasses?  :)
 >>
 >>Best Regards,
 >>Rajesh
 >>
 >>
 >>
 >>> Rajesh,
 >>> 
 >>> The DTN Bundle Protocol uses an obscure binary format for its
 >>> metadata blocks. If you want flexible user-definable metadata,
 >>> it really has to be text. For this reason, we proposed using HTTP
 >>> as a transport-layer-independent session layer for DTN networks:
 >>> 
 >>> http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-01
 >>> http://www.ietf.org/proceedings/08mar/slides/DTNRG-6.pdf
 >>> 
 >>> Getting content identification via MIME (which the Bundle Protocol
 >>> doesn't do) is a bonus. Gopher is an example of a binary format
 >>> that didn't succeed against HTTP.
 >>> 
 >>> L.
 >>> 
 >>> just another of those PhD-toting technicians.
 >>> 
 >>> DTN work: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
 >>> 
 >>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>
 >>> 
 >>> Rajesh Krishnan wrote on Sat 2008-05-10 1:02:
 >>> 
 >>> > Networks seem to need a critical mass of adoption, and usually an
 >>> > evolutionarily smart vector to succeed.  The DTN Bundle Protocol (or
 >>> its
 >>> > successor, with metadata extension block semantics that will
 >>> hopefully
 >>> > remain flexible and user-definable) might just offer an opportunity
 >>> for
 >>> > acquiring a new critical mass, but only if it finds the smart vector
 >>> > (that does what Mosaic did for HTTP/HTML, and perhaps BSD for
 >>> TCP/IP).
 >>> 
 >>> 
 >>

 cheers

   jon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080510/548c6600/attachment-0001.html