<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [e2e] end of interest -- BP metadata / binary vs text </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>BEEP gives us MIME, but is inherently rigidly transactional<BR>
(RFC3080 section 2.1.1), which puts it as a disadvantage<BR>
for long-delay links. HTTP PUTs can be entirely one-way...<BR>
never mind BEEP's profile uri's. (I do find the HTTP specs far<BR>
easier to read and follow.)<BR>
<BR>
HTTP, BEEP and the Bundle Protocol aren't network protocols...<BR>
really session layers (well, the BP's always compared to email,<BR>
and an email message can be thought of as a session?). Doing<BR>
sessions as text helps for debugging and modifications.<BR>
<BR>
L.<BR>
<BR>
<<A HREF="http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey.ac.uk/Personal/L.Wood/</A>><L.Wood@surrey.ac.uk><BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Jon Crowcroft [<A HREF="mailto:Jon.Crowcroft@cl.cam.ac.uk">mailto:Jon.Crowcroft@cl.cam.ac.uk</A>]<BR>
Sent: Sat 2008-05-10 17:19<BR>
To: Rajesh Krishnan<BR>
Cc: Wood L Dr (Electronic Eng); craig@aland.bbn.com; day@std.com; end2end-interest@postel.org; Jon.Crowcroft@cl.cam.ac.uk<BR>
Subject: Re: [e2e] end of interest -- BP metadata / binary vs text<BR>
<BR>
yep<BR>
<BR>
two alternates to the BP stuff suggest themselves...<BR>
<BR>
1. Blocks/BEEP:<BR>
<A HREF="http://www.ietf.org/rfc/rfc3080.txt">http://www.ietf.org/rfc/rfc3080.txt</A><BR>
if you are http mindfuk<BR>
and<BR>
2. some of the data naming/framing ideas in Reliable Multicast<BR>
<A HREF="http://portal.acm.org/citation.cfm?id=290808">http://portal.acm.org/citation.cfm?id=290808</A><BR>
if you are more rad<BR>
<BR>
In missive <1210432515.7973.171.camel@localhost.localdomain>, Rajesh Krishnan typed:<BR>
<BR>
>>Lloyd,<BR>
>><BR>
>>Yes, we discussed this on dtn-interest. What you say regarding text<BR>
>>being successful has been true of many application protocols, while<BR>
>>network/lower layer protocols favor a binary form. I do not have a<BR>
>>preference for either -- text is convenient until there is sizeable<BR>
>>metadata that is intrinsically binary (index shot thumbnail of a movie<BR>
>>scene).<BR>
>><BR>
>>I view BP or its successor as having the potential for being a<BR>
>>storage-aware network layer protocol rather than remain at the<BR>
>>session/application layer of a TCP/IP network. Rose-colored<BR>
>>glasses? :)<BR>
>><BR>
>>Best Regards,<BR>
>>Rajesh<BR>
>><BR>
>><BR>
>><BR>
>>> Rajesh,<BR>
>>><BR>
>>> The DTN Bundle Protocol uses an obscure binary format for its<BR>
>>> metadata blocks. If you want flexible user-definable metadata,<BR>
>>> it really has to be text. For this reason, we proposed using HTTP<BR>
>>> as a transport-layer-independent session layer for DTN networks:<BR>
>>><BR>
>>> <A HREF="http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-01">http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-01</A><BR>
>>> <A HREF="http://www.ietf.org/proceedings/08mar/slides/DTNRG-6.pdf">http://www.ietf.org/proceedings/08mar/slides/DTNRG-6.pdf</A><BR>
>>><BR>
>>> Getting content identification via MIME (which the Bundle Protocol<BR>
>>> doesn't do) is a bonus. Gopher is an example of a binary format<BR>
>>> that didn't succeed against HTTP.<BR>
>>><BR>
>>> L.<BR>
>>><BR>
>>> just another of those PhD-toting technicians.<BR>
>>><BR>
>>> DTN work: <A HREF="http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/">http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/</A><BR>
>>><BR>
>>> <<A HREF="http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey.ac.uk/Personal/L.Wood/</A>><L.Wood@surrey.ac.uk><BR>
>>><BR>
>>> Rajesh Krishnan wrote on Sat 2008-05-10 1:02:<BR>
>>><BR>
>>> > Networks seem to need a critical mass of adoption, and usually an<BR>
>>> > evolutionarily smart vector to succeed. The DTN Bundle Protocol (or<BR>
>>> its<BR>
>>> > successor, with metadata extension block semantics that will<BR>
>>> hopefully<BR>
>>> > remain flexible and user-definable) might just offer an opportunity<BR>
>>> for<BR>
>>> > acquiring a new critical mass, but only if it finds the smart vector<BR>
>>> > (that does what Mosaic did for HTTP/HTML, and perhaps BSD for<BR>
>>> TCP/IP).<BR>
>>><BR>
>>><BR>
>><BR>
<BR>
cheers<BR>
<BR>
jon<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>