Subject: [dtn] CBAR?

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 14 Aug 2015 21:31:40 +0000

Hi.  A technical issue on which we might try to reach consensus this month: from time to time, some of us have objected that SDNVs were not a convenient way to encode numeric values in bundles.  An alternative that has been proposed is Concise Binary Object Representation (CBOR, RFC 7049, https://tools.ietf.org/html/rfc7049).  One advantage of making this change is that it would align us with an RFC that is seeing increasingly wide use.  One disadvantage is that it would be a fairly pervasive change, and possibly a lot of work.  Any opinions?  Should we be looking at another alternative?  Or is SDNV good enough?

Scott

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Fri, 14 Aug 2015 22:45:32 +0000

Hi Scott.
Just to mention: the SDNV vs. CBOR topic has been discussed in the ANIMA
WG. SDNV was the first choice for GRASP (the ANIMA signaling protocol), but
there are some people in favor of using a JSON-like representation. One
point which is usually raised is the consideration of constrained devices.
In any case, it is not clear yet the choice in the context of ANIMA.
Best.

Jéferson Campos Nobre
PhD Student
Computer Networks Group - Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre

Em sex, 14 de ago de 2015 às 18:31, Burleigh, Scott C (312B) <
[email-masked]> escreveu:

> Hi.  A technical issue on which we might try to reach consensus this
> month: from time to time, some of us have objected that SDNVs were not a
> convenient way to encode numeric values in bundles.  An alternative that
> has been proposed is Concise Binary Object Representation (CBOR, RFC
> 7049, https://tools.ietf.org/html/rfc7049).  One advantage of making this
> change is that it would align us with an RFC that is seeing increasingly
> wide use.  One disadvantage is that it would be a fairly pervasive change,
> and possibly a lot of work.  Any opinions?  Should we be looking at another
> alternative?  Or is SDNV good enough?
>
>
>
> Scott
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Aug 2015 13:44:02 +0100

Hi Scott,

On 14/08/15 22:31, Burleigh, Scott C (312B) wrote:
> month: from time to time, some of us have objected that SDNVs were
> not a convenient way to encode numeric values in bundles.  An
> alternative that has been proposed is Concise Binary Object
> Representation (CBOR, RFC 7049, https://tools.ietf.org/html/rfc7049).
> One advantage of making this change is that it would align us with an
> RFC that is seeing increasingly wide use.  One disadvantage is that
> it would be a fairly pervasive change, and possibly a lot of work.
> Any opinions?  Should we be looking at another alternative?  Or is
> SDNV good enough?

I have no hard preference here, but if you were to move
away from SDNVs for 5050bis then I think it'd be kind of
weird to not simply move the whole BP to be entirely based
on e.g. JSON or CBOR - once implementations are using
libraries that support the alternative to SDNVs then you
may as well re-define so those libraries can en/decode
all the PDUs.

At which point I think you've maybe started more open-heart
surgery on the BP than was envisaged for this WG. (Which
could be a good idea, esp. from my POV, if the result was
a radical re-design and not simply a 5050bis activity, but
I digress:-)

S.

> 
> Scott
> 
> 
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2015 18:40:23 +0000

Going through RFC7049, CBOR seems to be very structured whereas
SDNV is unstructured. I think that gives it an advantage in that many
different binary object types can be represented without requiring
ancillary specification telling what each object is, which I think would
simplify RFC5050(bis) somewhat.

The three considerations I am aware of for encoding schemes are
1) processing efficiency,  2) network efficiency and  3) flexibility,
and I see CBOR as addressing each of these. The fact that it is an
already-published standard that seems to be gathering adoption
also gives it more of an "engineering" flavor where SDNV still
impresses me more as a "research" initiative.

CBOR and SDNV are very different, but I do not believe an exhaustive
comparison is necessary. I also think it is very natural for a research
initiative that is transitioning into the engineering domain to adopt
publish engineering standards during the standardization process.

That said, it would be interesting to get other perspectives from
those who may have more experience with coding schemes.

Thanks - Fred
[email-masked]

---

From: <[email-masked]>
Date: Mon, 17 Aug 2015 19:01:30 +0000

In addition, CBOR does allow arrays of data items, which might be an improvement for the dictionary. It may also be possible to remove the offset-related parameters, etc. In other words, some of the overhead of the primary block MAY be removed.

However, I'm not 100% sure that:
A) The benefits outweigh the potential overhead. If we can remove the offsets and replace them with a CBOR tagged type, that may be OK. The capability of SDNV to dynamically resize is useful, and I don't see a CBOR primitive which allows that. However, that isn't to say that it can't be done, or that we can't allow a range of primitive types.
B) The potential removal of SDNV's won't break/orphan other things: DTNMP utilizes SDNV, as does neighbor discovery and simple bundle security.

This is an largely subjective analysis, please, tear it apart.

Thanks,
Jeremy
________________________________________
From: dtn [[email-masked]] on behalf of Templin, Fred L [[email-masked]]
Sent: Monday, August 17, 2015 8:40 PM
To: Stephen Farrell; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] CBAR?

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Aug 2015 20:36:50 +0100

Andther consequence of CBOR is that you will get rid of
more RFC5050 code in most cases.

That has pros and cons of course.

If one assumes a well-tested CBOR library (and I don't know
the state of the art there, but for JSON you'd be sure), then
that is far less likely to be buggy compared to an RFC5050
en/decoder. (AFAIK, nobody has ever seriously attacked an
RFC5050 decoder, be interested if they had.)

OTOH, if someone considered they already have an excellent
RFC5050 implementation (I would not for DTN2, Scott might with
ION, not sure about others) then you might reasonably be
reluctant to make such a large change.

IMO, the case for changing to CBOR or JSON would be about
equally compelling though for slightly different reasons.
CBOR is much younger and less well supported than JSON (by
a few orders of magnitude in terms of numbers of developers),
but CBOR's goals do nicely match those for constrained DTN
implementations and for being stingy with bandwidth.

My own conclusion would be to argue to adopt JSON and to
re-factor the BP entirely with a view to making it easy to
support given modern JSON tooling.

Should the WG not like JSON so much, but prefer to make a
similar change to CBOR, (i.e. re-design around CBOR) I think
that'd be a little less good but still pretty reasonable.

Another option that the WG could try would be to move to
JSON now and then see how that looks and consider whether
CBOR is a useful optimisation, compared to the JSON variant.
That kind of difference could be relatively easily evaluated
fairly objectively if someone was willing to do the work.

Changing only the bits of 5050 that use SDNV encoding to use
either CBOR or JSON would be a bad mistake, achieving a worst
of all possible options outcome.

Leaving things as they are, with 5050bis using SDNVs would
be consistent with the WG charter of minimalistic change.
(But moving fully to either JSON or CBOR would be a better choice,
sez me:-)

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2015 19:55:47 +0000

Hi Stephen,

Understand, but if we are going to make a change like this we should
only do it once and not plan to do it again some years down the road.
IMHO, that would be a case for CBOR since it is already flexible and
extensible, and seems to be the trending way that other IETF work
is following.

Thanks - Fred

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, August 17, 2015 12:37 PM
> To: [email-masked]; Templin, Fred L; [email-masked]; [email-masked]
> Subject: Re: [dtn] CBAR?
> 
> 
> > In addition, CBOR does allow arrays of data items, which might be an improvement for the dictionary. It may also be possible to
> remove the offset-related parameters, etc. In other words, some of the overhead of the primary block MAY be removed.
> >
> > A) The benefits outweigh the potential overhead. If we can remove the offsets and replace them with a CBOR tagged type, that
> may be OK. The capability of SDNV to dynamically resize is useful, and I don't see a CBOR primitive which allows that. However, that
> isn't to say that it can't be done, or that we can't allow a range of primitive types.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Aug 2015 21:05:10 +0100

> only do it once and not plan to do it again some years down the road.

Agreed. What I was suggesting was to move to JSON now, then see if
someone will do the work to check how worthwhile the CBOR optimisation
would be. The structural change to JSON or CBOR will probably involve
all the same design choices and a subsequent change from JSON to CBOR
would be fairly mechanical I think (open to correction if not). So if
taking this path, I think the WG would either move to CBOR or not
before WGLC and not some years later.

> extensible, and seems to be the trending way that other IETF work

Well yes and no. There is some trend towards CBOR no question, but
it's not clear to me at least if that'll maintain momentum or not.
JSON is clearly going to be widely supported for decades to come
though. So CBOR is probably a better match but a bit of a risk.

(I'd consider betting on CBOR now similar to betting on BEEP some
years ago, before the eventual outcome was clear. In that case,
BEEP fell away, CBOR is more likely to survive would be my guess,
but it's clearly riskier than JSON by some unquantifiable amount.)

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2015 20:10:36 +0000

Hi Stephen,

> From: dtn [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, August 17, 2015 1:05 PM
> To: Templin, Fred L; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [dtn] CBAR?
> 
> 
> 

OK, but what about looking at it the other way around. Why not go to
CBOR now (simple pseudo-code is available directly in the spec) then
fall back to JSON before WGLC if it looks like CBOR is falling away?

Thanks - Fred

> >>> B) The potential removal of SDNV's won't break/orphan other things: DTNMP utilizes SDNV, as does neighbor discovery and
> simple
> >> bundle security.
> >>>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Aug 2015 21:15:26 +0100

> fall back to JSON before WGLC if it looks like CBOR is falling away?

I guess one could. I'd not argue for it though, because I prefer
JSON myself:-)

I think moving towards a more widely supported encoding format is
a good idea for the WG and JSON is *by far* more widely supported
so that's the basis on which I'd argue to go there first.

One could think of the move to JSON as doing the structural change
and then CBOR could be a pretty natural convergence layer maybe.

S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2015 20:46:50 +0000

Stephen,

> Sent: Monday, August 17, 2015 1:15 PM

I think we could go back and forth like this all day long and into the
next week, but that is not going to reach convergence. If there is
no way to reach convergence on CBOR/JSON, then the other
alternative is to just keep using SDNVs.

For the intended use cases for DTN, I am imagining low end devices
with low data rate and long delay links and that need to deal with
many data representation types. That means that we need a system
that is network efficient, small code footprint and flexible, which
sounds like the same sorts of requirements for routing protocols
like MANET. So, it might be worth asking what emerging routing
protocol specifications are asking for - CBOR or JSON?

> so that's the basis on which I'd argue to go there first.

For DTN, with reference to the use cases, widely supported IMHO takes
a distant back seat to efficiency, flexibility and ease of implementation.

Thanks - Fred

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 17 Aug 2015 18:09:51 -0400

Hi Fred:

On a personal note, I like the idea of using either CBOR or JSON better 
than using SDNV for reasons specified earlier in the conversation ... 
but I also don't have a strong enough opinion to really bother debating 
the point.  That said, a few notes inline.

> that is network efficient, small code footprint and flexible,

This statement strikes me as ambiguous.  If we're going to use "low end 
devices", "low data rate", "long delay", etc, as a justification for a 
WG decision, then I'd vote we carefully quantify these items in a 
separate RFC of some kind.  Otherwise, I believe such terms will cloud 
the debate.

> which

A few things:

* In my experience, wide support often means easier implementation: if 
something is widely supported, there's a pretty good chance reusable 
code (and reasonable documentation!) exists already.
* Efficiency is a rabbit hole in and of itself.  There's network 
efficiency, computational efficiency, memory efficiency, implementation 
efficiency, ... and even the more specific "computational efficiency" 
phrase depends to such an extent on the platform and the environment 
that the argument for / against "computational efficiency" strikes me as 
almost pointless without a specific use-case (preferably with 
performance measurements of some kind) to support the conversation.

Cheers,
Gilbert

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2015 22:19:36 +0000

Hi Gilbert,

> From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
> Sent: Monday, August 17, 2015 3:10 PM
> To: [email-masked]
> Subject: Re: [dtn] CBAR?
> 
> Hi Fred:
> 

Thanks, and I think I understand what you are saying. About use cases,
we debated about that a long time ago and came up with this:

https://tools.ietf.org/wg/dtn/trac/wiki/DtnUseCases

Regards - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Aug 2015 23:32:44 +0100

On 17/08/15 21:46, Templin, Fred L wrote:
> next week, but that is not going to reach convergence.

Well, there are presumably more voices involved in the WG
whose input will help. (So I'll bow out for now 'till we
see some more of those.)

I'd also not be pessimistic - my bet is that as one does
the work to transition to either JSON or CBOR it'll become
clear that the structural design choices that need to be
made are the same for both in almost all cases. CBOR is
really only a smallish set of variant rules for encoding
the same JSON-originated structures in a variously more
efficient manner.

So the apparent difference we've expressed so far will in
the end be shown to be almost entirely apparent.

Put another way, if the WG decided now to move to "JSON
or CBOR" that'd be just fine for quite a while.

> So, it might be worth asking what emerging routing

Off the top of my head - neither are being adopted in
IETF routing protocols at the moment. But I could well be
forgetting or just not know.

> For DTN, with reference to the use cases, widely supported
> IMHO takes a distant back seat to efficiency, flexibility
> and ease of implementation.

Widely supported is very much correlated with ease of
implementation once one considers that there are many
development environments in the universe. JSON will be
available & supported on basically all of those. CBOR will
not, today. Same for flexibility I think - JSON is inherently
more flexible than CBOR, which is partly why CBOR wins
on efficiency in various ways.

S.

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 17 Aug 2015 18:58:40 -0400

> or CBOR" that'd be just fine for quite a while.

+1 this.

-Gilbert

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Aug 2015 23:04:36 +0000

Hi Stephen,

> Sent: Monday, August 17, 2015 3:33 PM
> not, today.

Appendix C gives pseudocode that should guide implementations.
I don't know whether a CBOR "reference implementation" exists,
but I am not sure one is needed.

> Same for flexibility I think - JSON is inherently

CBOR allows encoding of many data types which would
provide ample flexibility for what BP needs. I'm not sure
there is a metric by which we would be able to say that
one system is "more flexible" than the other. AFAICT,
though, CBOR would be "flexible enough" for BP, and I'm
sure the same can be said about JSON.

I think this same discussion is probably going on in other
working groups, as it is not specific to DTN.

Thanks - Fred

---

From: Gilbert Clark <[email-masked]>
Date: Mon, 17 Aug 2015 19:23:38 -0400

> https://tools.ietf.org/wg/dtn/trac/wiki/DtnUseCases

I mean something that's a little more specific ... each of those 
use-cases seem like it would have a very different set of constraints.  
If we want to choose the lowest common denominator across each of those 
use-cases, then that's okay ... but I also think we should define what 
that is, exactly, to lend a little more context to conversations 
surrounding what is reasonable for a DTN node to attempt and what is not.

As an aside, I personally liked:

https://tools.ietf.org/html/rfc7228

Something like the above might lend context to a conversation, leading 
to less of a chance that folks talk past each other when trying to 
select particular technologies to use in specific circumstances.

-Gilbert

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 18 Aug 2015 06:56:56 +0000

Hello Fred and everyone:

I have two suggestions on this thread. 

Suggestion 1) It would be a good idea to move away from SDNV. 
I believe that the use of a data serialization format that enjoys wide-spread industry support will DTN's cause. Therefore, I would vote for moving away from SDNV. 

Suggestion 2) It could be a good idea to consider a wider array of vendor-neutral choices before finalizing on a specific format. 
- A robust data serialization format needs efficient multi-lingual (C, C++, and so on) implementations of encoders and decoders along with support by on-the-wire-data-inspectors (such as Wireshark). 

- Two text-based serialization formats enjoy unparalleled support, they are: XML and JSON, with XML being much older and more widely used than JSON. But, the problem with both the serialization formats is their inability to encode binary data without data-expansion. They both suggest using something like Base-64 encoding for inclusion of binary data in their formats. Base-64 encoding increases data size by a factor of 4/3 for large sized data (anything in Kilo-Bytes is deemed to be large-sized). Therefore, binary data transport is the Achilles Heel of both JSON and XML. Thus, several binary encoding formats are being developed 

- The following link may provide us with a good starting point for the wider array of choices: https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats I suggest that we sort the table provided in the link by clicking on the small arrows in the column named, "Binary ?" We may just be interested in those encoding that support binary data. 

- For example, there is a binary XML standardization effort using ASN.1 by ITU called Fast Infoset (http://www.itu.int/en/ITU-T/asn1/Pages/Fast-Infoset.aspx), which is indexed at the Wiki link provided above. 

- CBOR is also listed in the Wiki link provided above along with other data serialization techniques. 

Warm regards
Kapali 

-----Original Message-----
From: Templin, Fred L 
Sent: Tuesday, August 18, 2015 12:10 AM
To: Stephen Farrell; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] CBAR?

Going through RFC7049, CBOR seems to be very structured whereas SDNV is unstructured. I think that gives it an advantage in that many different binary object types can be represented without requiring ancillary specification telling what each object is, which I think would simplify RFC5050(bis) somewhat.

The three considerations I am aware of for encoding schemes are
1) processing efficiency,  2) network efficiency and  3) flexibility, and I see CBOR as addressing each of these. The fact that it is an already-published standard that seems to be gathering adoption also gives it more of an "engineering" flavor where SDNV still impresses me more as a "research" initiative.

CBOR and SDNV are very different, but I do not believe an exhaustive comparison is necessary. I also think it is very natural for a research initiative that is transitioning into the engineering domain to adopt publish engineering standards during the standardization process.

That said, it would be interesting to get other perspectives from those who may have more experience with coding schemes.

Thanks - Fred

---

From: Joerg Ott <[email-masked]>
Date: Tue, 18 Aug 2015 11:09:13 +0300

Let me add Carsten to this thread.

Jörg

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Aug 2015 11:07:50 +0200

Hi Joerg,

thanks for the pointer to this discussion.

I don't have particular insight into the need for DTN to switch from
SDNV (which is only part of an encoding solution) to something else.
That, of course, should not be done lightly.

The following comments are for the case that there indeed are some good
reasons to look at a new encoding format.

Clearly, XML and now JSON have good industry support within the
application development, web development, and protocol development
communities.  Recently, attention has shifted towards JSON, as its data
model often is close to what applications actually want to interchange.
 Two things are sometimes found missing in JSON: a way to (efficiently)
accommodate binary data, and a way to extend the set of data types
available in the data model towards the ones needed by the application
or protocol.

In conjunction with the work on constrained node networking (CoAP etc.),
we were looking for a data representation that would be applicable to
constrained nodes, maintain the popular JSON data model, while
addressing the two items above.
We analyzed a number of "binary JSONs" as well as other formats to see
whether we could just use them (see Appendix E of RFC 7049 for a quick
summary).  When we didn't quite find what we needed, we designed CBOR.

RFC 7049 was published less than two years ago, so of course it doesn't
have the range of implementations that JSON or XML have.  I'm trying to
keep a reasonably up to date list at:

	http://cbor.io/impls.html

Wireshark support is not there yet; the one implementation I know of is
available as part of the SPUD project:

	https://github.com/iptube/SPUDshark

Several IETF activities are now looking into using CBOR for their data
representation.  The most advanced one on the process side is the COSE
working group, which is defining security formats (object signing and
encryption) based on CBOR.  RTGAREA had an interesting discussion at
IETF93 about whether CBOR might be a better approach than inventing a
new TLV format for every new protocol:

	https://www.ietf.org/proceedings/93/slides/slides-93-rtgarea-3.pdf

I'm now subscribed to the DTN WG list, and I'm going to try answering
questions you might have about using CBOR with DTN.  (There also is a
(low-volume) CBOR specific mailing list, [email-masked].)

Grüße, Carsten

---

From: <[email-masked]>
Date: Tue, 18 Aug 2015 10:31:31 +0000

Couple of inputs here:

First, are we interested in JSON as a concept and interpreted as CBOR, or are we interested in JSON-on-the-wire. I am not a fan of the second, as JSON (in it's textual form) is much too verbose for low-capacity links. We should also be aware (or at least conscious) of the difficulties of implementing any serialization system which we chose on a FPGA or ASIC. Is the existing primary block perfectly suited for this? I would say no, is JSON better, again, I would say no, it's worse... Does a CBOR-based representation simplify this enough to justify the effort? 

CBOR is really cool, and in an alternate timeline, I am 100% convinced that we would be using it and this discussion wouldn't be happening. As is, I am having a lot of trouble convincing myself that the effort which would be required isn't better suited to other tasks. We have multiple implementations with which CCSDS has done interoperability testing, BP is being brought online in "real" applications. I think that (at this point) the second we start discussing the idea of a BP redesign, we're heading into dangerous waters.

Thanks,
Jeremy
________________________________________
From: dtn [[email-masked]] on behalf of I-Viswanathan, Kapaleeswaran [[email-masked]]
Sent: Tuesday, August 18, 2015 8:56 AM
To: [email-masked]
Subject: Re: [dtn] CBAR?

Hello Fred and everyone:

Warm regards
Kapali

-----Original Message-----
From: Templin, Fred L
Sent: Tuesday, August 18, 2015 12:10 AM
To: Stephen Farrell; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] CBAR?

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 12:40:39 +0100

On 18/08/15 11:31, [email-masked] wrote:
> Couple of inputs here:
> 
> First, are we interested in JSON as a concept and interpreted as
> CBOR, or are we interested in JSON-on-the-wire.

Good question. My take having pondered this overnight would
be that we ought define a MIME structure for use on-the-wire
in less challenged cases (e.g. with a TCP CL) and a JSON
structure for BP specifics within that.

So, e.g. what's now the primary block would be JSON-encoded
in a new application/bpprimary MIME type (or whatever) with
the bundle payload being whatever it is in another MIME body
part. (Yes, handling fragmentation would be fun, but then
isn't it always;-)

CBOR could then be usable as a different wire-format for an
alternative class of CLs for use when one is facing additional
challenges. The mapping from the above MIME-with-JSON on-the-wire
format to a CBOR form should be mechanical and easy to agree.
You'd just do all the obvious encoding stuff for the primary
block and map the payload MIME body part(s) into an array with
a (set of) numeric type and binary value. Easy-peasy:-)

> I am not a fan of the
> second, as JSON (in it's textual form) is much too verbose for
> low-capacity links. We should also be aware (or at least conscious)
> of the difficulties of implementing any serialization system which we
> chose on a FPGA or ASIC. Is the existing primary block perfectly
> suited for this? I would say no, is JSON better, again, I would say
> no, it's worse... 

I would maintain that FPGA or ASIC implementation is not the
mainstream even if it is more important for DTN than in other
cases. Overall the benefits of using a well supported form of
encoding are significant.

> Does a CBOR-based representation simplify this
> enough to justify the effort?

On an ASIC? Not sure to be honest, but I think that's the
wrong question myself.

> 
> CBOR is really cool, and in an alternate timeline, I am 100%
> convinced that we would be using it and this discussion wouldn't be
> happening. As is, I am having a lot of trouble convincing myself that
> the effort which would be required isn't better suited to other
> tasks. We have multiple implementations with which CCSDS has done
> interoperability testing, BP is being brought online in "real"
> applications. I think that (at this point) the second we start
> discussing the idea of a BP redesign, we're heading into dangerous
> waters.

Yes, that last is worth discussing. I'm clearly in the camp
that wants to do that re-design (and always did) but I agree
with you that being more minimalist and preserving more existing
code is entirely reasonable.

(About the only totally unreasonable thing here would be to
only replace SDNV-encoded fields with a new thing, that'd be
almost all the pain for little of the benefit.)

So it seems to me the decision tree here is something like:

- Do something radical about encoding for 5050bis?
    - No? Keep using SDNV
    - Yes? Pick an encoding scheme from:
       1) other, 2) xml, 3) "json or cbor"
          - 1) Other? What? Are you kidding? goto SDNV (or
               gobackto SDNV)
          - 2) xml? Yuk, goto fail:-)
          - 3) "JSON or CBOR" ? Win!!
                 - debate how to encode things afresh but significantly
                   better with much better dev support

Unsurprisingly "Yes, 3" would be my take:-)

I'm happy to go into the "why not xml" argument if needed but
I hope that JSON v. XML argument has been had sufficiently often
in the last 5 or so years that we can just #include it:-)

Cheers,S

> 
> Thanks, Jeremy ________________________________________ From: dtn
> [[email-masked]] on behalf of I-Viswanathan, Kapaleeswaran
> [[email-masked]] Sent: Tuesday, August 18, 2015
> 8:56 AM To: [email-masked] Subject: Re: [dtn] CBAR?
> 
> Hello Fred and everyone:
> 
> Suggestion 1) It would be a good idea to move away from SDNV. I
> believe that the use of a data serialization format that enjoys
> wide-spread industry support will DTN's cause. Therefore, I would
> vote for moving away from SDNV.
> 
> Suggestion 2) It could be a good idea to consider a wider array of
> vendor-neutral choices before finalizing on a specific format. - A
> robust data serialization format needs efficient multi-lingual (C,
> C++, and so on) implementations of encoders and decoders along with
> support by on-the-wire-data-inspectors (such as Wireshark).
> 
> - Two text-based serialization formats enjoy unparalleled support,
> they are: XML and JSON, with XML being much older and more widely
> used than JSON. But, the problem with both the serialization formats
> is their inability to encode binary data without data-expansion. They
> both suggest using something like Base-64 encoding for inclusion of
> binary data in their formats. Base-64 encoding increases data size by
> a factor of 4/3 for large sized data (anything in Kilo-Bytes is
> deemed to be large-sized). Therefore, binary data transport is the
> Achilles Heel of both JSON and XML. Thus, several binary encoding
> formats are being developed
> 
> - The following link may provide us with a good starting point for
> the wider array of choices:
> https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats
> I suggest that we sort the table provided in the link by clicking on
> the small arrows in the column named, "Binary ?" We may just be
> interested in those encoding that support binary data.
> 
> - For example, there is a binary XML standardization effort using
> ASN.1 by ITU called Fast Infoset
> (http://www.itu.int/en/ITU-T/asn1/Pages/Fast-Infoset.aspx), which is
> indexed at the Wiki link provided above.
> 
> Warm regards Kapali
> -----Original Message----- From: Templin, Fred L Sent: Tuesday,
> August 18, 2015 12:10 AM To: Stephen Farrell; Burleigh, Scott C
> (312B); [email-masked] Subject: Re: [dtn] CBAR?
> 
> Going through RFC7049, CBOR seems to be very structured whereas SDNV
> is unstructured. I think that gives it an advantage in that many
> ancillary specification telling what each object is, which I think
> would simplify RFC5050(bis) somewhat.
> 
> The three considerations I am aware of for encoding schemes are 1)
> processing efficiency,  2) network efficiency and  3) flexibility,
> already-published standard that seems to be gathering adoption also
> gives it more of an "engineering" flavor where SDNV still impresses
> me more as a "research" initiative.
> 
> comparison is necessary. I also think it is very natural for a
> research initiative that is transitioning into the engineering domain
> to adopt publish engineering standards during the standardization
> process.
> 
> Thanks - Fred [email-masked]
> 
>

---

From: <[email-masked]>
Date: Tue, 18 Aug 2015 12:04:45 +0000

We are now dangerously close to creating delay-tolerant S/MIME :) 

I don't think we should push that much logic into the CL, since now we have some weird-and-wonderful errata which comes into play. MIME/JSON to and from CBOR is fairly trivial, but do we need two whole classes of CL? What happens if I experience a sudden drop in throughput, do we need to give the CL/BP stack the ability to dynamically switch syntax? If so, are we sure, really truly sure that both sides can speak whatever the transmitter has decided is best (I'm going to say MIME-over-LTP-over-UDP, because that's weird and makes minimal sense). If not, do we now need a Delay-Tolerant Syntax Negotiation Protocol, where all inter-BP communication is prefixed by a IpSec-esque proposal exchange? Thar be dragons.

While I think FPGA-and-ASIC-based implementations will be minimal, the applications which require them will stress the design choices of BP, and we'll have to answer for them. That's why I put the question in there, I use it as my internal barometer for "is this design choice going to have horrible ugly ramifications down the road". 

I agree with your decision tree, except for the use of gotos :) As of now, I am in the camp of "no", but am open.
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Tuesday, August 18, 2015 1:40 PM
To: Mayer, Jeremy; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

Cheers,S

---

From: "Sheehe, Charles J. (GRC-LCA0)" <[email-masked]>
Date: Tue, 18 Aug 2015 12:12:56 +0000

Great 

Creating delay-tolerant S/MIME would make my life easier.
Operations Concept for a Solar System Internetwork (SSI)
IOAG.T.RC.001.V1

Chuck

Charles J. Sheehe III
Electronics Engineer
System Architectures and Networks Branch
21000 Brookpark Rd
Cleveland, OH 44135
[email-masked]
Office: 216-433-5179

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 18, 2015 8:05 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

On 18/08/15 11:31, [email-masked] wrote:
> Couple of inputs here:
>
> First, are we interested in JSON as a concept and interpreted as CBOR, 
> or are we interested in JSON-on-the-wire.

Good question. My take having pondered this overnight would be that we ought define a MIME structure for use on-the-wire in less challenged cases (e.g. with a TCP CL) and a JSON structure for BP specifics within that.

So, e.g. what's now the primary block would be JSON-encoded in a new application/bpprimary MIME type (or whatever) with the bundle payload being whatever it is in another MIME body part. (Yes, handling fragmentation would be fun, but then isn't it always;-)

CBOR could then be usable as a different wire-format for an alternative class of CLs for use when one is facing additional challenges. The mapping from the above MIME-with-JSON on-the-wire format to a CBOR form should be mechanical and easy to agree.
You'd just do all the obvious encoding stuff for the primary block and map the payload MIME body part(s) into an array with a (set of) numeric type and binary value. Easy-peasy:-)

> low-capacity links. We should also be aware (or at least conscious) of 
> the difficulties of implementing any serialization system which we 

I would maintain that FPGA or ASIC implementation is not the mainstream even if it is more important for DTN than in other cases. Overall the benefits of using a well supported form of encoding are significant.

> Does a CBOR-based representation simplify this enough to justify the 
> effort?

On an ASIC? Not sure to be honest, but I think that's the wrong question myself.

>
> CBOR is really cool, and in an alternate timeline, I am 100% convinced 
> that we would be using it and this discussion wouldn't be happening. 
> As is, I am having a lot of trouble convincing myself that the effort 
> which would be required isn't better suited to other tasks. We have 
> multiple implementations with which CCSDS has done interoperability 
> testing, BP is being brought online in "real"

Yes, that last is worth discussing. I'm clearly in the camp that wants to do that re-design (and always did) but I agree with you that being more minimalist and preserving more existing code is entirely reasonable.

(About the only totally unreasonable thing here would be to only replace SDNV-encoded fields with a new thing, that'd be almost all the pain for little of the benefit.)

I'm happy to go into the "why not xml" argument if needed but I hope that JSON v. XML argument has been had sufficiently often in the last 5 or so years that we can just #include it:-)

Cheers,S

> wide-spread industry support will DTN's cause. Therefore, I would vote 
> for moving away from SDNV.
>
> they are: XML and JSON, with XML being much older and more widely used 
> than JSON. But, the problem with both the serialization formats is 
> their inability to encode binary data without data-expansion. They 
> a factor of 4/3 for large sized data (anything in Kilo-Bytes is deemed 
> to be large-sized). Therefore, binary data transport is the Achilles 
> Heel of both JSON and XML. Thus, several binary encoding formats are 
> being developed
>
> - The following link may provide us with a good starting point for the 
> wider array of choices:
> -----Original Message----- From: Templin, Fred L Sent: Tuesday, August 
> 18, 2015 12:10 AM To: Stephen Farrell; Burleigh, Scott C (312B); 
> [email-masked] Subject: Re: [dtn] CBAR?
>
> processing efficiency,  2) network efficiency and  3) flexibility, and 
> I see CBOR as addressing each of these. The fact that it is an 
> gives it more of an "engineering" flavor where SDNV still impresses me 
> more as a "research" initiative.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 13:26:56 +0100

On 18/08/15 13:04, [email-masked] wrote:
> I don't think we should push that much logic into the CL, since now
> we have some weird-and-wonderful errata which comes into play.
> MIME/JSON to and from CBOR is fairly trivial, but do we need two
> whole classes of CL? 

Need? Not necessarily. But I figure it'd be reasonable if
5050bis had that, i.e. a TCPCL (or HTTPCL!) for which one
can *really really easily* develop an implementation and
a more terse encoding for CLs that can be mapped to the
"main" CL and that is aimed at the more constrained use
cases, and maybe based on CBOR. One would probably document
a UDPCL that used that encoding but some applications
would use different lower layers, e.g. ethernet or space
telemetry stuff or maybe AX.25, so the more constrained
form is really for a class of CLs and not just one, at
least as I think of it.

> What happens if I experience a sudden drop in
> throughput, do we need to give the CL/BP stack the ability to
> dynamically switch syntax?

My take: no. Once a BPA has handed a bundle to a CL for
transmission, then it's up to that CL to send or fail or
"partly send and stop" and then report back to the BPA on
how that all went. I think the BP handles that situation via
reactive fragmentation or else via custody based re-tx. A
specific CL could handle that kind of situation though
maybe. But such a CL would be getting as complex as maybe
a video codec so I don't think that'd be a great plan. I'd
not argue to change that in a 5050bis myself.

In our DTN2/LTPlib, BP/LTP work our LTPCL code can handle a
whole bunch of disruptions (e.g. ephemeris handling, link
outages etc) without having to tell the BPA about 'em all.
ION does that differently though and most of ION's control
or config for handling disruptions is common to the BPA and
the CL. But RFC5050 and the LTPCL works for both, and the
two implementations even interoped fine in many situations.
So there's also plenty of scope for implementations to handle
many of those things differently but still be ok.

Cheers,
S.

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 18 Aug 2015 12:46:14 +0000

Hi Carsten

Many thanks for the detailed response. 

I have been using the following document to gain insight into the original intention for developing SDNV for DTN. Specifically, Section 1.1 was useful to understand the novelty (or unique value proposition) of SDNV for DTN.  
https://tools.ietf.org/html/rfc6256

A natural question to ask may be: how does CBOR solve this problem that SDNV solves? And, how does it solve it differently than SDNV. 

Additionally, I found the following link to be useful in understanding DTN for space applications. 
http://public.ccsds.org/publications/archive/734x0g1e1.pdf

Best regards
Kapali 

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 2:38 PM
To: Joerg Ott
Cc: I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBOR?

Hi Joerg,

I don't have particular insight into the need for DTN to switch from SDNV (which is only part of an encoding solution) to something else.
That, of course, should not be done lightly.

The following comments are for the case that there indeed are some good reasons to look at a new encoding format.

Clearly, XML and now JSON have good industry support within the application development, web development, and protocol development communities.  Recently, attention has shifted towards JSON, as its data model often is close to what applications actually want to interchange.
 Two things are sometimes found missing in JSON: a way to (efficiently) accommodate binary data, and a way to extend the set of data types available in the data model towards the ones needed by the application or protocol.

In conjunction with the work on constrained node networking (CoAP etc.), we were looking for a data representation that would be applicable to constrained nodes, maintain the popular JSON data model, while addressing the two items above.
We analyzed a number of "binary JSONs" as well as other formats to see whether we could just use them (see Appendix E of RFC 7049 for a quick summary).  When we didn't quite find what we needed, we designed CBOR.

RFC 7049 was published less than two years ago, so of course it doesn't have the range of implementations that JSON or XML have.  I'm trying to keep a reasonably up to date list at:

Wireshark support is not there yet; the one implementation I know of is available as part of the SPUD project:

Several IETF activities are now looking into using CBOR for their data representation.  The most advanced one on the process side is the COSE working group, which is defining security formats (object signing and
encryption) based on CBOR.  RTGAREA had an interesting discussion at
IETF93 about whether CBOR might be a better approach than inventing a new TLV format for every new protocol:

I'm now subscribed to the DTN WG list, and I'm going to try answering questions you might have about using CBOR with DTN.  (There also is a
(low-volume) CBOR specific mailing list, [email-masked].)

Grüße, Carsten

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 18 Aug 2015 13:05:37 +0000

Hi Jeremy:

There are two subjects in this mail. 

Subject 1) Expression of understanding and opinion. 
My understanding is that SDNV, CBOR, and binary XML are comparable serialization formats because all their encoders produce binary outputs. JSON and XML encoders produce text outputs.  So, I agree with you that sending JSON on DTN links is not optimal. 

Subject 2) Expression of understanding and query. 
>> I am having a lot of trouble convincing myself that the effort which would be required isn't better suited to other tasks. We have multiple implementations with which CCSDS has done interoperability testing, BP is being brought online in "real" applications. I think that (at this point) the second we start discussing the idea of a BP redesign, we're heading into dangerous waters.

I understand that the primary reason in the above paragraph arguing against a change away from SDNV as the amount of expended effort in achieving CCDS interoperability testing for BP with SDNV. As also the amount of effort to be expended for testing BP interoperability with CCSDS protocol suites when BP may choose to use a different encoding approach. 

It would be useful to understand the dependency between SDNV and successful CCSDS interoperability testing of BP or of CCSDS File Delivery Protocol. Are there any documents that can help us understand the same?

Also, in order to understand the CCSDS standardization process, I looked at the following well maintained URL. What is the current colour code for Bundle Protocol within the CCSDS standardization process?
 
http://public.ccsds.org/publications/StandardsDevProcess.aspx   

Many thanks. 

Best regards
Kapali 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 4:02 PM
To: I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: RE: [dtn] CBAR?

Couple of inputs here:

Thanks,
Jeremy

Hello Fred and everyone:

Warm regards
Kapali

-----Original Message-----
From: Templin, Fred L
Sent: Tuesday, August 18, 2015 12:10 AM
To: Stephen Farrell; Burleigh, Scott C (312B); [email-masked]
Subject: Re: [dtn] CBAR?

Thanks - Fred

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Aug 2015 15:32:12 +0200

> A natural question to ask may be: how does CBOR solve this problem that SDNV solves? And, how does it solve it differently than SDNV. 

Any TLV scheme needs a solution for the "L" (length) aspect.
Of course, CBOR also does the "T" (type) aspect, but this answer is
about "L".  Simple TLV schemes can often get by with a fixed-length
length, but as RFC 6256 notes, this can be both wasteful and limiting.
SDNV-style schemes have been around for a while (ASN.1 BER uses them,
MIDI calls them VLQs, a little endian variant called LEB128 is in the
DWARF file format and in the Dalvik executable format), but base-128 is
not the only way to do variable length numbers.

In CBOR, the initial byte of a data item provides both type information
(3 bits) and length information (5 bits).  Instead of providing one
continuation bit in each byte (and the resulting bit-shifting), CBOR
uses the initial 5-bit value either as an immediate value (0..23) or to
indicate how many additional bytes of length information are present
(24..27 for 1, 2, 4, or 8 bytes; we did not see much value in supporting
3, 5, 6 or 7 byte variants).

The same encoding is also used directly for integer values and for
counting elements in arrays and pairs in maps; it also can be used to
indicate additional data types such as time values, bignums, decimal
floats, etc. via the concept of "tags".

So a text string "XYZ" is encoded by an initial byte carrying 0b011 for
text and 0b00011 for the length three, then the three bytes "XYZ".
A 140-byte byte string would be encoded by an initial byte carrying
0b010 for bytes and 0b11000 (24) calling for one additional byte for the
length, that second byte carrying the uint8_t for 140, and 140 bytes of
data.

Play around at http://cbor.me for translating JSON-like "CBOR diagnostic
format" to bytes and back, e.g.

	http://cbor.me/?bytes=63(58595a)

for the first example.

Grüße, Carsten

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 18 Aug 2015 13:36:17 +0000

Subject 1) MIME
MIME was created because SMTP, which was (and is) the dominant mail delivery standard, defined an ASCII-text channel for transportation and later faced the need to transport non-ASCII text and non-text messages. 
https://en.wikipedia.org/wiki/MIME 

Since SDNV defines a binary channel and BP might logically move to another binary channel (such as CBOR), what would be the utility of something like MIME for BP? 

Subject 2) JSON Versus MIME
I agree that this discussion is best avoided in this list. It is not productive. At the end of the day, we should take the best available technology for creating a binary channel for DTN applications. The tricky part is to define what is best for Bundle Protocol. 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 5:11 PM
To: [email-masked]; I-Viswanathan, Kapaleeswaran; [email-masked]
Subject: Re: [dtn] CBAR?

Cheers,S

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 14:38:08 +0100

On 18/08/15 13:46, I-Viswanathan, Kapaleeswaran wrote:
> A natural question to ask may be: how does CBOR solve this problem
> that SDNV solves? And, how does it solve it differently than SDNV.

FWIW, I think that is not a good question to ask.

"JSON or CBOR" makes sense to consider as an alternative to the
RFC5050 encoding of a bundle. A part, but only a part, of that
relates to SDNVs. The question above assume that the change from
SDNV is the interesting question when the interesting question
is the change from RFC5050's home grown encoding to using a
better supported form of encoding, for the entire bundle.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 14:43:43 +0100

On 18/08/15 14:36, I-Viswanathan, Kapaleeswaran wrote:
> Subject 1) MIME MIME was created because SMTP, which was (and is) the
> dominant mail delivery standard, defined an ASCII-text channel for
> transportation and later faced the need to transport non-ASCII text
> and non-text messages. https://en.wikipedia.org/wiki/MIME
> 
> Since SDNV defines a binary channel and BP might logically move to
> another binary channel (such as CBOR), what would be the utility of
> something like MIME for BP?

Eh? SDNVs are only used for numbers and cryptovariables
in 5050 and not for bundle payload. See my other mail about SDNVs
being a distraction for the decision. (While SDNVs are a distraction
in terms of which decision to make they can usefully motivate us
to make a decision.)

> 
> Subject 2) JSON Versus MIME I agree that this discussion is best
> avoided in this list. 

I didn't see any "JSON vs. MIME" discussion so I'm not sure what
you mean.

S.

> It is not productive. At the end of the day, we
> should take the best available technology for creating a binary
> channel for DTN applications. The tricky part is to define what is
> best for Bundle Protocol.
> 
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Tuesday, August 18, 2015
> 5:11 PM To: [email-masked]; I-Viswanathan, Kapaleeswaran;
> Good question. My take having pondered this overnight would be that
> we ought define a MIME structure for use on-the-wire in less
> challenged cases (e.g. with a TCP CL) and a JSON structure for BP
> specifics within that.
> 
> So, e.g. what's now the primary block would be JSON-encoded in a new
> application/bpprimary MIME type (or whatever) with the bundle payload
> being whatever it is in another MIME body part. (Yes, handling
> fragmentation would be fun, but then isn't it always;-)
> 
> format to a CBOR form should be mechanical and easy to agree. You'd
> just do all the obvious encoding stuff for the primary block and map
> the payload MIME body part(s) into an array with a (set of) numeric
> type and binary value. Easy-peasy:-)
> 
>> I am not a fan of the second, as JSON (in it's textual form) is
>> much too verbose for low-capacity links. We should also be aware
>> (or at least conscious) of the difficulties of implementing any
>> serialization system which we chose on a FPGA or ASIC. Is the
>> existing primary block perfectly suited for this? I would say no,
>> is JSON better, again, I would say no, it's worse...
> 
> mainstream even if it is more important for DTN than in other cases.
> Overall the benefits of using a well supported form of encoding are
> significant.
> 
>> Does a CBOR-based representation simplify this enough to justify
>> the effort?
> 
>> happening. As is, I am having a lot of trouble convincing myself
>> that the effort which would be required isn't better suited to
>> other tasks. We have multiple implementations with which CCSDS has
>> done interoperability testing, BP is being brought online in
>> "real" applications. I think that (at this point) the second we
>> start discussing the idea of a BP redesign, we're heading into
>> dangerous waters.
> 
> Yes, that last is worth discussing. I'm clearly in the camp that
> wants to do that re-design (and always did) but I agree with you that
> being more minimalist and preserving more existing code is entirely
> reasonable.
> 
> (About the only totally unreasonable thing here would be to only
> replace SDNV-encoded fields with a new thing, that'd be almost all
> the pain for little of the benefit.)
> 
> - Do something radical about encoding for 5050bis? - No? Keep using
> SDNV - Yes? Pick an encoding scheme from: 1) other, 2) xml, 3) "json
> or cbor" - 1) Other? What? Are you kidding? goto SDNV (or gobackto
> SDNV) - 2) xml? Yuk, goto fail:-) - 3) "JSON or CBOR" ? Win!! -
> debate how to encode things afresh but significantly better with much
> better dev support
> 
> I'm happy to go into the "why not xml" argument if needed but I hope
> that JSON v. XML argument has been had sufficiently often in the last
> 5 or so years that we can just #include it:-)
> 
> Cheers,S
> 
>> 
>> [[email-masked]] Sent: Tuesday, August 18,
>> 2015 8:56 AM To: [email-masked] Subject: Re: [dtn] CBAR?
>> 
>> Hello Fred and everyone:
>> 
>>  robust data serialization format needs efficient multi-lingual
>> (C, C++, and so on) implementations of encoders and decoders along
>> with support by on-the-wire-data-inspectors (such as Wireshark).
>> 
>> used than JSON. But, the problem with both the serialization
>> formats is their inability to encode binary data without
>> data-expansion. They both suggest using something like Base-64
>> encoding for inclusion of binary data in their formats. Base-64
>> encoding increases data size by a factor of 4/3 for large sized
>> data (anything in Kilo-Bytes is deemed to be large-sized).
>> Therefore, binary data transport is the Achilles Heel of both JSON
>> and XML. Thus, several binary encoding formats are being developed
>> 
>> (http://www.itu.int/en/ITU-T/asn1/Pages/Fast-Infoset.aspx), which
>> is indexed at the Wiki link provided above.
>> 
>> SDNV is unstructured. I think that gives it an advantage in that
>> many different binary object types can be represented without
>> requiring ancillary specification telling what each object is,
>> which I think would simplify RFC5050(bis) somewhat.
>> 
>> CBOR and SDNV are very different, but I do not believe an
>> exhaustive comparison is necessary. I also think it is very natural
>> for a research initiative that is transitioning into the
>> engineering domain to adopt publish engineering standards during
>> the standardization process.
>>

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 18 Aug 2015 14:30:19 +0000

Subject 1) 
Quote > I didn't see any "JSON vs. MIME" discussion so I'm not sure what you mean.
Sorry about the typo. The statement was meant to be JSON Versus XML (not MIME). JSON versus XML is not a useful discussion in this thread is what I meant to say. 

Subject 2)
Quote > SDNVs are only used for numbers and cryptovariables in 5050 and not for bundle payload. See my other mail about SDNVs being a distraction for the decision. (While SDNVs are a distraction in terms of which decision to make they can usefully motivate us to make a decision.)

Yes. The use of SDNVs is indicated in https://tools.ietf.org/html/rfc5050#section-4 and  https://tools.ietf.org/html/rfc5050#section-4.5. 

The conversation snippet below is about MIME, JSON, primary blocks, and payloads. The question still remains:  what would be the utility of something like MIME for BP? In other words, what new capability does something like MIME bring to BP? 

Best regards
Kapali 

------------Conversation snippet----------
Jeremy> 
First, are we interested in JSON as a concept and interpreted as CBOR, or are we interested in JSON-on-the-wire.

Stephen> 

------------Conversation snippet----------

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 7:14 PM
To: I-Viswanathan, Kapaleeswaran; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

> something like MIME for BP?

Eh? SDNVs are only used for numbers and cryptovariables in 5050 and not for bundle payload. See my other mail about SDNVs being a distraction for the decision. (While SDNVs are a distraction in terms of which decision to make they can usefully motivate us to make a decision.)

> Subject 2) JSON Versus MIME I agree that this discussion is best 

I didn't see any "JSON vs. MIME" discussion so I'm not sure what you mean.

S.

> It is not productive. At the end of the day, we should take the best 
> available technology for creating a binary channel for DTN 
> applications. The tricky part is to define what is best for Bundle 
> Protocol.
> 
> 
> Good question. My take having pondered this overnight would be that we 
> ought define a MIME structure for use on-the-wire in less challenged 
> cases (e.g. with a TCP CL) and a JSON structure for BP specifics 
> within that.
> 
>> I am not a fan of the second, as JSON (in it's textual form) is much 
>> too verbose for low-capacity links. We should also be aware (or at 
>> least conscious) of the difficulties of implementing any 
>> existing primary block perfectly suited for this? I would say no, is 
>> JSON better, again, I would say no, it's worse...
> 
> Yes, that last is worth discussing. I'm clearly in the camp that wants 
> to do that re-design (and always did) but I agree with you that being 
> more minimalist and preserving more existing code is entirely 
> reasonable.
> 
> replace SDNV-encoded fields with a new thing, that'd be almost all the 
> pain for little of the benefit.)
> 
> SDNV) - 2) xml? Yuk, goto fail:-) - 3) "JSON or CBOR" ? Win!! - debate 
> how to encode things afresh but significantly better with much better 
> dev support
> 
>> deemed to be large-sized).

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 15:38:21 +0100

On 18/08/15 15:30, I-Viswanathan, Kapaleeswaran wrote:
> Subject 1) Quote > I didn't see any "JSON vs. MIME" discussion so I'm
> not sure what you mean. Sorry about the typo. The statement was meant
> to be JSON Versus XML (not MIME). JSON versus XML is not a useful
> discussion in this thread is what I meant to say.

Ah good. Yes I agree JSON vs XML has played at a cinema near
all of us enough times already:-)

> 
> Subject 2) Quote > SDNVs are only used for numbers and
> cryptovariables in 5050 and not for bundle payload. See my other mail
> about SDNVs being a distraction for the decision. (While SDNVs are a
> distraction in terms of which decision to make they can usefully
> motivate us to make a decision.)
> 
> Yes. The use of SDNVs is indicated in
> https://tools.ietf.org/html/rfc5050#section-4 and
> https://tools.ietf.org/html/rfc5050#section-4.5.
> 
> The conversation snippet below is about MIME, JSON, primary blocks,
> and payloads. The question still remains:  what would be the utility
> of something like MIME for BP? In other words, what new capability
> does something like MIME bring to BP?

Loads. There are about 3-4 code bases that can en/decode RFC5050.
And zero of those is installed on a randomly selected device that
is sometimes connected to the Internet.

There are loads and loads of implementations of MIME and JSON. And
those are far better tested I'd bet. And that functionality is
available on pretty much all platforms, and easy to use.

In retrospect, I think DTNRG erred in developing a home-grown
encoding and the DTN WG could, if it so chooses, fix that. The
result would be that it would be much easier to "DTN enable" many
applications on the Internet. It would probably make little or
no difference to e.g. deep-space networking though, that is true.

S.

> 
> Best regards Kapali
> 
> ------------Conversation snippet---------- Jeremy> First, are we
> interested in JSON as a concept and interpreted as CBOR, or are we
> interested in JSON-on-the-wire.
> 
> Stephen> Good question. My take having pondered this overnight would
> be that we ought define a MIME structure for use on-the-wire in less
> 7:14 PM To: I-Viswanathan, Kapaleeswaran; [email-masked];
>> Subject 1) MIME MIME was created because SMTP, which was (and is)
>> the dominant mail delivery standard, defined an ASCII-text channel
>> for transportation and later faced the need to transport non-ASCII
>> text and non-text messages. https://en.wikipedia.org/wiki/MIME
>> 
>>  another binary channel (such as CBOR), what would be the utility
>> of something like MIME for BP?
> 
> Eh? SDNVs are only used for numbers and cryptovariables in 5050 and
> not for bundle payload. See my other mail about SDNVs being a
> distraction for the decision. (While SDNVs are a distraction in terms
> of which decision to make they can usefully motivate us to make a
> decision.)
> 
>> 
>> It is not productive. At the end of the day, we should take the
>> best available technology for creating a binary channel for DTN 
>> So, e.g. what's now the primary block would be JSON-encoded in a
>> new application/bpprimary MIME type (or whatever) with the bundle
>> payload being whatever it is in another MIME body part. (Yes,
>> handling fragmentation would be fun, but then isn't it always;-)
>> 
>>  just do all the obvious encoding stuff for the primary block and
>> map the payload MIME body part(s) into an array with a (set of)
>> numeric type and binary value. Easy-peasy:-)
>> 
>>> convinced that we would be using it and this discussion wouldn't
>>> be happening. As is, I am having a lot of trouble convincing
>>> myself that the effort which would be required isn't better
>>> suited to other tasks. We have multiple implementations with
>>> which CCSDS has done interoperability testing, BP is being
>>> brought online in "real" applications. I think that (at this
>>> point) the second we start discussing the idea of a BP redesign,
>>> we're heading into dangerous waters.
>> 
>> wants to do that re-design (and always did) but I agree with you
>> that being more minimalist and preserving more existing code is
>> entirely reasonable.
>> 
>>  SDNV - Yes? Pick an encoding scheme from: 1) other, 2) xml, 3)
>> "json or cbor" - 1) Other? What? Are you kidding? goto SDNV (or
>> gobackto SDNV) - 2) xml? Yuk, goto fail:-) - 3) "JSON or CBOR" ?
>> Win!! - debate how to encode things afresh but significantly better
>> with much better dev support
>> 
>> I'm happy to go into the "why not xml" argument if needed but I
>> hope that JSON v. XML argument has been had sufficiently often in
>> the last 5 or so years that we can just #include it:-)
>> 
>> Cheers,S
>> 
>>> 
>>>  [[email-masked]] Sent: Tuesday, August
>>> 18, 2015 8:56 AM To: [email-masked] Subject: Re: [dtn] CBAR?
>>> 
>>> Hello Fred and everyone:
>>> 
>>> Suggestion 2) It could be a good idea to consider a wider array
>>> of vendor-neutral choices before finalizing on a specific format.
>>> - A robust data serialization format needs efficient
>>> multi-lingual (C, C++, and so on) implementations of encoders and
>>> decoders along with support by on-the-wire-data-inspectors (such
>>> as Wireshark).
>>> 
>>> - Two text-based serialization formats enjoy unparalleled
>>> support, they are: XML and JSON, with XML being much older and
>>> more widely used than JSON. But, the problem with both the
>>> serialization formats is their inability to encode binary data
>>> without data-expansion. They both suggest using something like
>>> Base-64 encoding for inclusion of binary data in their formats.
>>> Base-64 encoding increases data size by a factor of 4/3 for large
>>> sized data (anything in Kilo-Bytes is deemed to be large-sized). 
>>> Therefore, binary data transport is the Achilles Heel of both
>>> JSON and XML. Thus, several binary encoding formats are being
>>> developed
>>> 
>>> - The following link may provide us with a good starting point
>>> for the wider array of choices: 
>>> https://en.wikipedia.org/wiki/Comparison_of_data_serialization_format
>>>
>>> 
s
>>> - For example, there is a binary XML standardization effort
>>> using ASN.1 by ITU called Fast Infoset 
>>> 1) processing efficiency,  2) network efficiency and  3)
>>> flexibility, and I see CBOR as addressing each of these. The fact
>>> that it is an already-published standard that seems to be
>>> gathering adoption also gives it more of an "engineering" flavor
>>> where SDNV still impresses me more as a "research" initiative.
>>> 
>>> exhaustive comparison is necessary. I also think it is very
>>> natural for a research initiative that is transitioning into the

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Tue, 18 Aug 2015 15:06:07 +0000

Hi Stephen

Many thanks. 

Best regards
Kapali 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 8:08 PM
To: I-Viswanathan, Kapaleeswaran; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

> discussion in this thread is what I meant to say.

Ah good. Yes I agree JSON vs XML has played at a cinema near all of us enough times already:-)

> 
> Subject 2) Quote > SDNVs are only used for numbers and cryptovariables 
> in terms of which decision to make they can usefully motivate us to 
> make a decision.)
> 

Loads. There are about 3-4 code bases that can en/decode RFC5050.
And zero of those is installed on a randomly selected device that is sometimes connected to the Internet.

There are loads and loads of implementations of MIME and JSON. And those are far better tested I'd bet. And that functionality is available on pretty much all platforms, and easy to use.

In retrospect, I think DTNRG erred in developing a home-grown encoding and the DTN WG could, if it so chooses, fix that. The result would be that it would be much easier to "DTN enable" many applications on the Internet. It would probably make little or no difference to e.g. deep-space networking though, that is true.

S.

>>> that the effort which would be required isn't better suited to other 
>>> applications. I think that (at this
>> SDNV) - 2) xml? Yuk, goto fail:-) - 3) "JSON or CBOR" ?
>>> vendor-neutral choices before finalizing on a specific format.
>>> - A robust data serialization format needs efficient multi-lingual 
>>> is their inability to encode binary data without data-expansion. 
>>> They both suggest using something like
s
>>> that it is an already-published standard that seems to be gathering 
>>> adoption also gives it more of an "engineering" flavor where SDNV 
>>> still impresses me more as a "research" initiative.
>>> 
>>> research initiative that is transitioning into the engineering 
>>> domain to adopt publish engineering standards during the 
>>> standardization process.
>>>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 18 Aug 2015 15:37:57 +0000

Hi All,

Sorry for the top-post but this is more of a summary of experience than 
a direct reply.

I have spent the last year experimenting with implementing a 'DTN-lite' 
protocol in JSON, blatantly stealing the concepts from 5050 without the 
wire protocol, and my results have been mixed, but mostly promising.

Pros:

* Client applications can easily interface with their local BPA in a 
nice Web2.0 style (great for the latest generation of grad students)

* Key/Value pairs, objects and arrays along with of-the-shelf parsing 
makes validating and handling the set of bundle blocks easy.

* Extensions and experiments are easily handled as there is no strict 
schema.

Cons:

* Binary blobs.  These are a pain in JSON, base64 is just band-aid.

   ** I've ended up using JSON-encoding for all blocks apart from the 
payload, in a 're-inventing chunked http' style.

   ** CRCs and crypto hashes of immutable blocks in JSON is not simple: 
whitespace has no meaning but can alter any checksum.

* It's not a suitable over-the-air format.

* If there is a pre-agreed protocol, why do I have to pass around Keys 
for each of my Key/Value pairs?  Some kind of schema would really help here.

But:

* CBOR may be the answer to many of these issues, such as the CRCs and 
binary payloads.

* The design of the underlying CL has always been to pass the JSON (or 
CBOR) down to the CL and let it compress and transfer as it sees fit, or 
pass-the-buck as we call it.

In conclusion:

* I love being able to describe the various blocks in a bundle in terms 
of JSON objects and arrays, it feels natural to me.  I can look at the 
protocol in terms of data items their meaning rather than bits, and that 
helps a lot.

* Formatted text is not the solution over the wire, but it is very 
suitable for a local BPA to user application API, and really helpful 
when discussing the protocol.

* JSON<->CBOR looks like it works well and may solve some of the binary 
blob issues.

Ironically, my intention is to prototype a RFC5050bis to JSON transcoder 
in order to interoperate with a larger DTN, so maybe a JSON bundle 
protocol need not actually replace the 5050bis work, but perhaps be a 
parallel task aiming longer term?

Cheers,

Rick Taylor
Airbus

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 18 Aug 2015 16:05:13 +0000

I think there's a fundamental misconception here that ought to be addressed.

Using JSON or CBOR (or whatever) as as basis for the on-the-wire representation of bundle information would not significantly accelerate the development of bundle protocol implementations.

Composing and parsing bundles is far and away the easiest, most trivial and mechanical thing that a bundle protocol agent does.  Simplifying the development of that code would have negligible impact on implementation development.

Anybody who seriously needs JSON support in order to produce bundle construction and parsing code is going to be a little over his head when he has to take on fragmentation, reassembly, custody transfer, quality of service, bundle status reports, congestion control, routing, a generalized extension management mechanism, and (way more challenging than all the rest of this stuff) safe and efficient resource management.

Using CBOR in place of SDNV could have some modest recurring benefit, offset by some (probably modest) non-recurring cost.  Let's not make more of it than it is.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Tuesday, August 18, 2015 5:26 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 17:06:26 +0100

Hi Rick,

Good stuff.

Almost all of what you say makes perfect sense but I'm not getting
this one bit...

> when discussing the protocol.

Let's say we want to send a bundle over a non-challenged
link, plenty of CPU on either side and no significant
bandwidth constraint while the link is up. (My experience
of DTN experiments that we have deployed has been that most
bundle transmissions are in fact like this.)

And let's say we send the bundle as a MIME multipart body
with the first body-part being the primary block as a flattened
JSON object (or array, whatever:-) and the 2nd being the
payload with whatever is the appropriate MIME type and using
a binary/8bit transfer encoding. And let's further say that
there are no extension blocks in this case.

What are the downsides you see in this case? (That's what
I don't get.)

If you could also say what changes to the scenario would cause
significant downsides that'd be useful for me too, e.g., adding
extensions maybe, or crypto, I can see either being a bit of
a pain. (JOSE should handle crypto stuff, albeit with b64
overhead and other slightly flakey JOSE-nesses;-) Clearly if
one needs the most terse encoding possible then the above isn't
it so I'm more asking about any more subtle things of which
you're aware. I'd also be interested if you think the above
would perhaps be easier to support/integrate than a CBOR or
other more b/w efficient encoding.

If the WG pursue this direction, I think it'd be interesting
do the analysis above in detail and see where the pain-points
actually arise.

My argument is that doing the above, plus a CBOR encoding for
other CLs, would perhaps be the best combination. And as well
as being (I think) easier to integrate, I like the above scheme
because we can be sure (basically) that JSON will be around in
decades, whereas nice as it may be, we just do not know that
for CBOR, so I'd not be happy to put all my eggs in Carsten's
basket at this point in time (good and all as he is with eggs:-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 17:10:04 +0100

Hi Scott,

On 18/08/15 17:05, Burleigh, Scott C (312B) wrote:
> Using JSON or CBOR (or whatever) as as basis for the on-the-wire
> representation of bundle information would not significantly
> accelerate the development of bundle protocol implementations.

I really don't agree.

Most developers will not be implementing a general purpose
bundle router.

Most developers do not have enough time to implement 5050 or
any similar home-grown codec.

The above are sufficient reasons for real-world developers to
not use 5050 and to re-invent delay-tolerance at the application
layer over and over IMO. (There may be others but I'm convinced
of the above. )

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 18 Aug 2015 16:24:54 +0000

Stephen, I don't see what you're disagreeing with.  You're absolutely right, most developers don't have time to implement codecs.  They shouldn't have to.  You only need to develop a codec when you're developing a protocol implementation, which most developers don't need to do.  All they need to do is develop applications that utilize well-supported implementations of protocols.

Sure, JSON or S/MIME might be a great way to encode the payloads of bundles, which applications are going to read and write, and which (therefore) lots of developers can benefit from.

But there's no reason for application developers to be developing implementations of BP itself, in the same way that there's no reason for application developers to be developing their own implementations of TCP.  These are two entirely different development communities.

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Tuesday, August 18, 2015 9:10 AM
To: Burleigh, Scott C (312B); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

Hi Scott,

I really don't agree.

Cheers,
S.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 18 Aug 2015 16:33:50 +0000

Hi Stephen,

> Sent: Tuesday, August 18, 2015 9:06 AM
> To: Rick Taylor; Templin, Fred L; [email-masked]
> Subject: Re: [dtn] CBAR?
> 
> 
> Hi Rick,
> 
> Good stuff.
> 

Carsten is not the one holding the basket - the IETF is, and they have
approved CBOR as a proposed standard.

Thanks - Fred

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 17:51:29 +0100

Hiya,

On 18/08/15 17:24, Burleigh, Scott C (312B) wrote:
> Stephen, I don't see what you're disagreeing with.  You're absolutely
> right, most developers don't have time to implement codecs.  They
> shouldn't have to.  You only need to develop a codec when you're
> developing a protocol implementation, which most developers don't
> need to do.  All they need to do is develop applications that utilize
> well-supported implementations of protocols.

The BP is not well-supported in that sense. JSON is. And
so is MIME. (CBOR is not yet.)

Unless this WG make the kinds of change that treat ease of
development and deployment as a first class requirement, we'll
sadly never get to where one can say that the BP is well-
supported in such a sense, is my prediction. The immediate
consequence is that developers will just not use RFC5050bis.

I'll even repeat that:-) Ease of development and deployment
for an average application developer who does not control
the network should be first class requirements.

That, or else fail-for-sure except for a few niches, is the
real choice here.

> 
> Sure, JSON or S/MIME might be a great way to encode the payloads of
> bundles, which applications are going to read and write, and which
> (therefore) lots of developers can benefit from.
> 
> But there's no reason for application developers to be developing
> implementations of BP itself, in the same way that there's no reason
> for application developers to be developing their own implementations
> of TCP.  These are two entirely different development communities.

Yep, we disagree. Many application developers are quite
able to and do emit HTML forms with file attachments, and
shoot those down a socket or HTTP session and they're
quite able to consume those on servers with relatively
fine support from even simple things like PHP. (And the
basic MIME+JSON encoding I'm arguing for could be just as
simple or maybe even the same:-)

The same holds true for anything that's easily handled
via widely available libraries that are already likely to
be deployable and where bundles can transit the middleboxes
that are deployed today, without requiring any change to
those middleboxes.

Most developers are not able to encode or decode an RFC5050
primary bundle block or anything similar (if for no other
reason than they do not have time) and hence 5050 will remain
unused unless you can tell me why phone, web server and other
deployers would include a BPA on the relevant devices. And
then of course even if you got there, deployed middleboxes
would prevent all current BP CLs from working.

To be successful, an RFC5050bis needs to be something that
an application developer can choose to adopt without having
to wait for all platforms or middleboxes to have adopted.

The WG can of course choose to ignore this kind of issue, as
we (mistakenly) did in the DTNRG and will be glad no doubt
when I go quiet again as a result:-) But if the WG ignore
this and prioritise e.g. bandwidth efficiency then developers
will continue to ignore or re-invent delay-tolerance as they
will have no other reasonable choice.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Aug 2015 18:54:45 +0200

Templin, Fred L wrote:
>> > JSON will be around in

Thanks, Fred, I was going to say a similar thing (and the CBOR community
also is larger than the IETF community, random links below).

Grüße, Carsten

[1] http://code.haskell.org/~duncan/binary-experiment/binary.pdf
[2]
https://github.com/meiersi/HaskellerZ/blob/master/meetups/20150529-ZuriHac2015_Duncan_Coutts-Better_Faster_Binary_Serialization/binary.pdf

[3] https://github.com/01org/tinycbor
[4] https://github.com/BurntSushi/rust-cbor
[5] http://search.cpan.org/~mlehmann/CBOR-XS-1.3/XS.pm
...

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 18 Aug 2015 21:42:14 +0000

Sure, ease of application development is a first-class requirement.  BP is not an application that needs to be developed by large numbers of developers, and it surely won't be.  Making BP itself easy to develop is a consideration, but JSON/SMIME bundle representation is not going to drive that.

Sent from my Verizon 4G LTE Smartphone

------ Original message------

From: Stephen Farrell

Date: Tue, Aug 18, 2015 12:51 PM

To: Burleigh, Scott C (312B);[email-masked];[email-masked];[email-masked];

Cc:

Subject:Re: [dtn] CBAR?

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 22:51:13 +0100

Hiya,

On 18/08/15 22:42, Burleigh, Scott C (312B) wrote:
> BP is not an application that needs to be developed by large numbers
> of developers, and it surely won't be.

Ok, that's the source of our disagreement then.

I think the BP is just a protocol that has nice delay
tolerant features and can be implemented in any way
by anyone who wants to use that protocol in their
application.

I guess you're considering the BP more as a service
accessed via an API that a BPA provides to applications.
(That roughly right?)

For me, it makes just as much sense for the creator of
a bundle to be a bit of Javascript code running in a
browser. With HTML5 LocalStorage and WebCrypto that'd
now make much more sense than it would have 15 ago, so
it would be quite practical. Presumably in that case,
the web origin with which the JS can communicate would
be the (front end for) the next hop DTN router.

I really don't see why we would want to prevent that
kind of thing.

Cheers,
S.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 18 Aug 2015 22:15:08 +0000

Hi, Stephen.  Yes, it looks like that's exactly where we diverge.  I agree that the source of a bundle could be a bit (a fairly substantial bit) of Javascript code running in a browser, but if 2000 application developers independently develop that bit of code then I suspect 1990 of them will get significant bits of it critically wrong.

BP has a number of nice delay-tolerant features that are challenging to implement well.  We could dumb down the protocol to make it easier to implement, but then we don't provide good support for those features.

If we don't dumb it down, it will require substantial investments in time and attention to implement BP.  In that case, either there will be a small number of reusable,tested, well-supported and documented, publicly available implementations or else a large number of people are going to be endlessly reinventing the wheel.  Possibly somebody would feel comfortable about paying for the latter, but I'm doubtful.

If the former, the time and effort required to implement the codec component of the protocol is trivial in comparison to the rest, in which case I see nothing compelling about using JSON, S/MIME, etc.

I think it makes way more sense to provide carefully crafted, tested, and efficient (efficient in transmission, efficient in acquisition, efficient in storage, efficient in computation) implementations in jarfiles, libraries, etc. as a service to application developers.  It's less work for developers, and it's less bloat on users' hardware.

I certainly wouldn't want to prevent anybody from developing anything they want.  But nothing I'm talking about would do that.

Scott
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Tuesday, August 18, 2015 2:51 PM
To: Burleigh, Scott C (312B); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

Hiya,

Cheers,
S.

---

From: Keith Scott <[email-masked]>
Date: Tue, 18 Aug 2015 18:17:00 -0400

---------- Forwarded message ----------
From: "Keith Scott" <[email-masked]>
Date: Aug 18, 2015 6:01 PM
Subject: Re: [dtn] CBAR?
To: "Scott C Burleigh (313B)" <[email-masked]>
Cc:

I think I'm with Scott here.  Ease of access to BP services is important,
but development of a BP infrastructure, even if it's browser based as in
your example,  is probably not something lots of people will want to
develop (import,  maybe).

A good solid api, maybe a set of normalized language bindings so that
applications can be portable. I'm assuming more of a 'BP in the stack'
model but that shifts load / complexity from application developers to BP
implementations, I think.

  Keith
On Aug 18, 2015 5:43 PM, "Burleigh, Scott C (312B)" <
[email-masked]> wrote:

> Sure, ease of application development is a first-class requirement.  BP is
> not an application that needs to be developed by large numbers of
> developers, and it surely won't be.  Making BP itself easy to develop is a
> consideration, but JSON/SMIME bundle representation is not going to drive
> that.
>
>
> *From: *Stephen Farrell
> *Date: *Tue, Aug 18, 2015 12:51 PM
>
> *To: *Burleigh, Scott C (312B);[email-masked];
> [email-masked];[email-masked];
>
> *Cc: *
>
> *Subject:*Re: [dtn] CBAR?
>
>
>
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Aug 2015 23:45:59 +0100

On 18/08/15 23:15, Burleigh, Scott C (312B) wrote:
> i, Stephen.  Yes, it looks like that's exactly where we diverge. 

Ok, good. I agree that your view doesn't call for the same
kind of things for developers. (And still think you're
wrong of course:-)

> I
> agree that the source of a bundle could be a bit (a fairly
> substantial bit) of Javascript code running in a browser, but if 2000
> application developers independently develop that bit of code then I
> suspect 1990 of them will get significant bits of it critically
> wrong.

Disagree. One could quite easily make it very simple to get
that correct. The MIME+JSON thing I outlined is basically the
same as a web form that posts a file and is routinely produced
by JS code. All of that really is quite doable and could be
done well with today's web development environments. And it
could be done in such as way that the rest of a DTN (which may
indeed be designed in the manner you're think of) would also
be improved.

Yes, doing so would indeed be a more radical change than was
envisaged when this WG was chartered, but it really would be
worthwhile going down the "JSON or CBOR" route.

S.

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 03:00:36 +0000

> Many application developers are quite

( I quite like http://bsonspec.org/ )

If only MIME and JSON/BSON could be done in a DTN environment using the universal HTTP substrate that application developers expect.

If only.

Lloyd Wood
http://http-dtn.sf.net/

If only there existed a specification describing this, prototypes demonstrating this, and academic papers testing this. If only.
________________________________________
From: dtn <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Wednesday, 19 August 2015 2:51 AM
To: Burleigh, Scott C (312B); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dtn] CBAR?

Hiya,

Cheers,
S.

---

From: Rick Taylor <[email-masked]>
Date: Wed, 19 Aug 2015 08:57:45 +0000

Hi Stephen,

> Good stuff.

Thanks, it's all very much a lab experiment at the moment.

>> when discussing the protocol.

Sorry, this is a compound statement.

I was hedging my bets with the first part of the sentence:  I imagine 
some people will legitimately argue that for very constrained links, 
using JSON with lots of pretty whitespace is not bandwidth efficient.

The second part of the sentence refers to my application model: I have a 
bundle agent that provides DTN facilities to local LAN applications, and 
I use JSON/TCP for the bundle submission/receptions API.

The third part of the sentence refers to how easy it is to draw JSON 
snippets on a white-board/fag-packet in order to work out where I'm 
going wrong.

> bundle transmissions are in fact like this.)

I agree with you here.  Certainly in my use-cases the links, when they 
appear, are fast and fat, it's just that they can be very intermittent. 
  But I think this is the other end of the link characteristics spectrum 
from the deep space guys.

> What are the downsides you see in this case? (That's what

The only downsides I have are the checksums/hashes of the immutable 
first block, which I don't bother with at the moment, but if end-to-end 
security is a concern then it might become an issue.  Note, I haven't 
looked at JOSE (yet).

> other more b/w efficient encoding.

I'm not yet in a good position to come back with data-supported 
suggestions as I'm half-way through the investigation, but I should have 
some more detail later this year (not the most useful, sorry!)

As far as CBOR is concerned, I'm not currently using it, as bandwidth 
efficiency is not my primary concern, but having looked at many 
alternatives (BSON, roll-my-own, Google protocol-buffers) I rather like 
CBOR from an engineering perspective.

Putting things in a HTTP/MIME-ish way: I see JSON and CBOR as 
Content-Encoding for non-payload bundle blocks, and in my way of 
thinking there is nothing to stop an intermediate node from transforming 
Content-Encodings to meet some CL link requirements.

> do the analysis above in detail and see where the pain-points

I totally agree, but I will need to check what the Airbus position is 
concerning contributing output from my current work.  That being said, 
they are, in general, IETF positive.

> basket at this point in time (good and all as he is with eggs:-)

I think there is real advantage in splitting the DTN work into effort 
spent defining behaviours of nodes, defining requirements with fairly 
loose abstract parameters, and this is where JSON really helps; and 
considerations for the behaviour of convergence layers for various types 
of links, e.g. deep-space, MANET, HOMENET.

Of course, the WG already has a charter...

Rick

---

From: <[email-masked]>
Date: Wed, 19 Aug 2015 09:16:33 +0000

> Certainly in my use-cases the links, when they 

Not quite a spectrum.

See fig 1 of 
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/e-dtn-oct-2009-wood-position-paper.pdf

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: dtn <[email-masked]> on behalf of Rick Taylor <[email-masked]>
Sent: Wednesday, 19 August 2015 6:57 PM
To: Stephen Farrell; Templin, Fred L; [email-masked]
Subject: Re: [dtn] CBAR?

Hi Stephen,

Rick

---

From: Rick Taylor <[email-masked]>
Date: Wed, 19 Aug 2015 09:49:29 +0000

> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/e-dtn-oct-2009-wood-position-paper.pdf

Thanks Lloyd, nice diagram.

Perhaps I should have said "other corner of the 2D spectrum" ;-)

Rick

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 12:03:50 +0000

Hi Rick:

Thanks for sharing the nice summary. 

* Client applications can easily interface with their local BPA in a nice Web2.0 style (great for the latest generation of grad students)

Have you considered developing a reactor patter with BPA underneath? I am tempted to say this because of your "grad students" mention. Something like Node.JS, Vertx (http://vertx.io/), and so on. You can also try Futures and promises based programming syntax on top of bundles. 

Yes, I agree. This is because JSON defines a text channel and transporting binary data over text channel is really band aid. 

Best regards
Kapali 

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 9:08 PM
To: Templin, Fred L; [email-masked]
Subject: Re: [dtn] CBAR?

Hi All,

Sorry for the top-post but this is more of a summary of experience than a direct reply.

I have spent the last year experimenting with implementing a 'DTN-lite' 
protocol in JSON, blatantly stealing the concepts from 5050 without the wire protocol, and my results have been mixed, but mostly promising.

Pros:

* Client applications can easily interface with their local BPA in a nice Web2.0 style (great for the latest generation of grad students)

* Key/Value pairs, objects and arrays along with of-the-shelf parsing makes validating and handling the set of bundle blocks easy.

* Extensions and experiments are easily handled as there is no strict schema.

Cons:

   ** I've ended up using JSON-encoding for all blocks apart from the payload, in a 're-inventing chunked http' style.

* If there is a pre-agreed protocol, why do I have to pass around Keys for each of my Key/Value pairs?  Some kind of schema would really help here.

But:

* CBOR may be the answer to many of these issues, such as the CRCs and binary payloads.

* The design of the underlying CL has always been to pass the JSON (or
CBOR) down to the CL and let it compress and transfer as it sees fit, or pass-the-buck as we call it.

In conclusion:

* I love being able to describe the various blocks in a bundle in terms of JSON objects and arrays, it feels natural to me.  I can look at the protocol in terms of data items their meaning rather than bits, and that helps a lot.

* Formatted text is not the solution over the wire, but it is very suitable for a local BPA to user application API, and really helpful when discussing the protocol.

* JSON<->CBOR looks like it works well and may solve some of the binary blob issues.

Ironically, my intention is to prototype a RFC5050bis to JSON transcoder in order to interoperate with a larger DTN, so maybe a JSON bundle protocol need not actually replace the 5050bis work, but perhaps be a parallel task aiming longer term?

Cheers,

Rick Taylor
Airbus

On 17/08/15 23:19, Templin, Fred L wrote:
>> On a personal note, I like the idea of using either CBOR or JSON 
>> better than using SDNV for reasons specified earlier in the conversation ...
>> but I also don't have a strong enough opinion to really bother 
>> debating the point.  That said, a few notes inline.
>>
>> This statement strikes me as ambiguous.  If we're going to use "low 
>> end devices", "low data rate", "long delay", etc, as a justification 
>> for a WG decision, then I'd vote we carefully quantify these items in 
>> a separate RFC of some kind.  Otherwise, I believe such terms will 
>> cloud the debate.
>>
>>> which
>>>> I think moving towards a more widely supported encoding format is a 
>>>> good idea for the WG and JSON is *by far* more widely supported so 
>>>> that's the basis on which I'd argue to go there first.
>>> For DTN, with reference to the use cases, widely supported IMHO 
>>> takes a distant back seat to efficiency, flexibility and ease of implementation.
>>
>> A few things:
>>
>> * In my experience, wide support often means easier implementation: 
>> if something is widely supported, there's a pretty good chance 
>> reusable code (and reasonable documentation!) exists already.
>> efficiency, computational efficiency, memory efficiency, 
>> implementation efficiency, ... and even the more specific "computational efficiency"
>> that the argument for / against "computational efficiency" strikes me 
>> as almost pointless without a specific use-case (preferably with

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 12:10:38 +0000

Hi Carsten

Many thanks for the detailed response. I now understand the fundamental difference between CBOR and SDNV. CBOR is a TLV scheme while SDNV is not. SDNV only encodes numbers while CBOR can encode numbers, text, and so on. 

I am still playing around with the CBOR playground to understand its utility. 

Best regards
Kapali 

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2015 7:02 PM
To: I-Viswanathan, Kapaleeswaran
Cc: [email-masked]
Subject: Re: [dtn] CBOR?

Any TLV scheme needs a solution for the "L" (length) aspect.
Of course, CBOR also does the "T" (type) aspect, but this answer is about "L".  Simple TLV schemes can often get by with a fixed-length length, but as RFC 6256 notes, this can be both wasteful and limiting.
SDNV-style schemes have been around for a while (ASN.1 BER uses them, MIDI calls them VLQs, a little endian variant called LEB128 is in the DWARF file format and in the Dalvik executable format), but base-128 is not the only way to do variable length numbers.

In CBOR, the initial byte of a data item provides both type information
(3 bits) and length information (5 bits).  Instead of providing one continuation bit in each byte (and the resulting bit-shifting), CBOR uses the initial 5-bit value either as an immediate value (0..23) or to indicate how many additional bytes of length information are present
(24..27 for 1, 2, 4, or 8 bytes; we did not see much value in supporting 3, 5, 6 or 7 byte variants).

The same encoding is also used directly for integer values and for counting elements in arrays and pairs in maps; it also can be used to indicate additional data types such as time values, bignums, decimal floats, etc. via the concept of "tags".

So a text string "XYZ" is encoded by an initial byte carrying 0b011 for text and 0b00011 for the length three, then the three bytes "XYZ".
A 140-byte byte string would be encoded by an initial byte carrying
0b010 for bytes and 0b11000 (24) calling for one additional byte for the length, that second byte carrying the uint8_t for 140, and 140 bytes of data.

Play around at http://cbor.me for translating JSON-like "CBOR diagnostic format" to bytes and back, e.g.

for the first example.

Grüße, Carsten

---

From: Rick Taylor <[email-masked]>
Date: Wed, 19 Aug 2015 12:39:17 +0000

> Have you considered developing a reactor patter with BPA underneath? I am tempted to say this because of your "grad students" mention. Something like Node.JS, Vertx (http://vertx.io/), and so on. Y…

Yes, I have, I prefer the Proactor pattern personally, it works well for 
our production code so I'm reusing the bits and pieces we have sat around.

The larger point is a simple clean API for applications based around 
web-ish technology has some huge potential benefits.

Rick

---

From: "I-Viswanathan, Kapaleeswaran" <[email-masked]>
Date: Wed, 19 Aug 2015 12:49:43 +0000

Hi Rick

Thanks for the reference to Proactor Pattern. Is the following paper a good reference for the same?

http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf

Best regards
Kapali 

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2015 6:09 PM
To: I-Viswanathan, Kapaleeswaran; Templin, Fred L; [email-masked]
Subject: Re: [dtn] CBAR?

> Have you considered developing a reactor patter with BPA underneath? I am tempted to say this because of your "grad students" mention. Something like Node.JS, Vertx (http://vertx.io/), and so on. Y…

Yes, I have, I prefer the Proactor pattern personally, it works well for our production code so I'm reusing the bits and pieces we have sat around.

The larger point is a simple clean API for applications based around web-ish technology has some huge potential benefits.

Rick

>>> for a WG decision, then I'd vote we carefully quantify these items 
>>> in a separate RFC of some kind.  Otherwise, I believe such terms 
>>> will cloud the debate.
>>>
>>>> which
>>> that the argument for / against "computational efficiency" strikes 
>>> me as almost pointless without a specific use-case (preferably with 
>> Thanks, and I think I understand what you are saying. About use 
>> cases, we debated about that a long time ago and came up with this:
>>

---

From: Sebastian Schildt <[email-masked]>
Date: Wed, 19 Aug 2015 21:14:16 +0200

Hi *

I think the idea here is that for the use cases envisioned by Stephen you do not need to implement a lot of „significant bits" where you could get wrong.

For example, when we developed the Mail CL (SMTP/IMAP) we encoded bundles using MIME and extracted PBB headers and converted them to MIME headers directly. As a side-result,  we had a small snippet of PHP code, that could encode a valid RFC5050 mail and fire it off to the mailbox of a „real" BPA. This would have been a million times harder, when trying to generate the native on-wire format of RFC5050 with PHP (for MIME and stuff there is just a lot of existing tooling). At the the same time the PHP "BP implementation", did not (need to) do 99% of the stuff a BPA needs to handle. It just could inject a certain type of standard bundles (without custody etc.) into "the DTN". WITHOUT having to rely on a full-blown RFC5050 implementation running on the server. 

Whether this is motivation enough to change the BP format radically, I do not know. But it is a demonstration that some of the benefits mentioned by the JSOB/CBOR/… proponents are certainly realistic.

Sebastian

P.S.: But please binary. Except wanting to run on small (insert your definition of small here) devices, also do not forget the BP is just a tool for transporting data that matters: The payload. You do not know how it looks like. And you do not want to Base64 all that….

> On 19 Aug 2015, at 00:15, Burleigh, Scott C (312B) <[email-masked]> wrote:
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 20 Aug 2015 12:49:23 +0000

Good point, Sebastian.  We could certainly define multiple classes of BPAs of varying levels of capability, so that protocol conformance wouldn't always have to be so onerous.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Sebastian Schildt [[email-masked]]
Sent: Wednesday, August 19, 2015 12:14 PM
To: Burleigh, Scott C (312B)
Cc: [email-masked]; [email-masked]; [email-masked]; Stephen Farrell
Subject: Re: [dtn] CBAR?

Hi *

Sebastian