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

Rajesh Krishnan rkrishnan at comcast.net
Sat May 10 08:15:15 PDT 2008


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).
> 
> 



More information about the end2end-interest mailing list