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

[Jon Crowcroft]

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