[dtn-interest] Comments on RFC 5050

[Michael Noisternig <[e-mail]>]

Continuing my review (part 2/3) with RFC 5050...

4. Bundle Format:
"At most one of the blocks in the sequence may be a payload block." 
Would it be advanteous to allow more payload blocks with different 
(e.g., security) processing?

4.1. SDNVs:
I am not convinced this is the best solution. Even if we acknowledge 
that some flexible way to encode variable-length data is needed protocol 
designers are still faced with the decision whether to directly 
SDNV-encode some data field or instead SDNV-encode a length field such 
as to more efficiently carry lengthy data. Why not combine the current 
SDNV solution with some UTF-8-like encoding, such that the length of the 
data field is implicitly encoded?

The protocol also includes several byte values that are not 
SDNV-encoded: Version field, Block Type code, etc. These could easily be 
declared SDNV values without loosing backwards compatibility (to 
currently defined values) or processing efficiency.

4.2. Bundle Processing Control Flags:
"if fields are added
    in the future, the SDNV will grow to the left, and using this
    representation allows the references here to remain valid."
I see no reason why references should become invalid if the field would 
grow to the right with bit number 0 put on the left. The present 
representation has the disadvantage that the whole field needs to be 
received first before standard flags (those in earlier versions) can be 
parsed.

Flag 0 "Bundle is a fragment.": This flag obviously refers to the 
payload block, only, but could it be desirable to support fragmentation 
in other blocks as well such as in "optional" extension blocks?

Flag 4 "Destination endpoint is a singleton.": Requiring this knowledge 
seems to be in direct conflict with late binding.

4.3., last paragraph:
Why the restriction that "the block processing flags must be set to zero 
on all blocks that follow the payload block"?

4.4. Endpoint EIDs:
"Each endpoint ID conveyed in any bundle block takes the form of a 
Uniform Resource Identifier (URI; [URI])."
URIs are nice in being human-readable but they are also very wordy. It 
would be beneficial to generalize the current notion to support any kind 
of encoding (including binary) for the scheme-specific part given an 
(ASCII) scheme name. This is crucial for bandwidth-constrained 
environments, and definitely sufficient for applications that don't span 
multiple networks.

"This array is simply the concatenation of any number of null-terminated 
scheme names and SSPs."
Instead of null-terminating strings, why not encode them with prefixed 
SDNV length values? This seems to make the design more consistent and 
may improve string copy operations. But that's a minor comment.

4.7. Dictionary Revision:
"Any [unreferenced] strings (scheme names and SSPs) in a bundle's 
dictionary ... may be removed from the
    dictionary at the time the bundle is forwarded."
...subject to that authenticity is not lost.

5.2. Bundle Transmission, step 2:
"... with current custodian endpoint ID set to the null endpoint ID 
"dtn:none"
It should be up to the source to decide whether to support custody 
transfer, i.e., whether to set the current custodian EID to the source 
EID or to dtn:none.

5.6. Bundle Reception, step 4:
"If [a duplicate bundle has been received that] has the
       retention constraint "Custody accepted", custody transfer
       redundancy must be handled."
Why are processing steps 2 and 3, which generate bundle reception status 
reports, being executed before step 4?