MIME Type Extension Block

[CryptoCopter]

According to the standard, a bundle's payload is just a bunch of bytes, and it includes no mechanism to specify the payloads "file-format".

So I was thinking about creating an ExtensionBlock to basically serve the same use as the HTTP Content-Type-header.

[CryptoCopter]

@gh0st42 do you have any such mechanism in dtn7-rs?

[gh0st42]

not really. I mean if it is BP-specific you can use a custom block type. We have done this in the past for location blocks that allow us to send GPS coordinates. We also did this to have a payload independent way of adding addition meta information in a standardized way.

Other than that usually the service name/number should indicate what kind of payload is to be expected.

In general, if I have an address such as dtn://node1/imagedump I would expect a payload with a contained image or if it's something like dtn://chatgroup/~xmpp then the payload should be XML with jabber stuff.
In these cases, one should still verify that the received payload is valid, an additional header does not help here.
The same applies for IPN naming scheme.

So I'm not seeing which problem is really solved as service names in the addressing scheme should already give you a hint of what is to be expected in the payload.
Extension blocks increase bundles sizes and introduce complexity, and in this case they might even be misleading as some could take the mime type for truth, not implementing their own verification then leading to security issues as payloads get parsed with the wrong mime type.

[mogren]

Sounds good... Is the idea to follow the HTTP/1.1 RFC spec, using https://pkg.go.dev/mime that implements RFC 2046?