Change:
[TODO: This is inconsistent with {prop-cap-profile}} - needs to be fixed] <ins> 7.3.9. Boolean This property specifies that a message should be sent and received as a single packet without transport-layer segmentation or network-layer fragmentation.  Attempts to send a message with this property set with a size greater to the transport's current estimate of its maximum transmission segment size will result in a "SendError".  When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set. </ins> 7.4. It is not always possible for an application to send all data

Discussion:
Alternate fix for fragmentation/segmentation prohibited in a single message property, per discussion. Merge only one of these. :)
Discussion on identified that we probably want a Message (and/or Connection) property that forces DF on for IPv4 (and, I guess, ensures that datagram sends on IPv6 below MTU will fail, by disabling sender fragmentation, as well).
This should also prevent IPv4 sender fragmentation. It's possible to generate IPv4 fragments from the stack with the DF set. I think the property should default to do this, and I'd suggest "ALLOW Network Fragementation" as a suggested name.
This has to be a Message Property, however, we expect programmers to typically set this property on a Connection or Preconnection (as default for all messages).
NAME so you say "network fragmentation". This excludes fragmentation in the host, which we may also want to control if we want to send unfragmented PMTU-sized packets. On the other hand, if this includes fragmentation in the host, your suggested default will always fail for TCP when I send messages > PMTU, yet in case of a TCP-like service I really don't want to care about this. => My suggestion would be to just to drop the word "network" and (alas) NOT make forbid-fragmentation the default. NAME it has to be a Message Property, yes. But what makes you say that you'd expect programmers to typically set this on a Connection or a Preconnection?
NAME the only use case to set this on a per-message basis I can image is PMTU discovery and I hope this is usually done by the transport system implementaion
NAME I agree with you but don't see the relationship with setting that on a Connection or Preconnection.
Agreed to the general point that this is a useful property! To the discussion of where it goes, I agree with NAME We had discussed letting defaults for Messages be set connection-wide for convenience, so I think the point is that this would commonly be set as a convenient default, rather than having the application set it over and over.
After reading again, I get the feeling we actually need two properties: Allow Fragmentation for the Messages passed to the transport service. Allow IP level Fragmentation for the Packets generated by the transport protocol. Now it becomes ugly: For UDP, both are equivalent.

For TCP/QUIC, the former set to false means that sending a message should fail if the exceeds the PMTU after passing the framer. This also implies that a message should be sent within a single packet. For TCP/QUIC, the latter set to false means that the transport system should set the DF flag for v4 and disable local fragmentation for v6, but the transport protocol can still split a message into multiple packets. While the former definitely works as discussed so far, I have no idea what should happen if the latter is set to false on a message but the former is set to true…
Not sure about QUIC, but what you say here about TCP isn't right: none of this should matter to TCP, you can't control DF with it and the PMTU shouldn't be visible to the application.
More on philsbln's note above: I'm putting TCP aside, and assuming he's right about QUIC: 1) The former set to false, but the latter to true: "a message should be sent within a single packet" - but then we want to be able to allow network-layer fragmentation? That seems strange to me. 2) The latter set to false, but the former to true: so here we want the DF flag, but it's still ok to split messages across multiple packets. Again, that seems strange to me. => I struggle to see a use case for any of these combinations. My proposal would be to have only one boolean property that controls both IP- and transport-level fragmentation (allowing or forbidding both).
while I was writing , I also came to think that this should be a single message context property whose implementation was context-dependent made more sense. I'm happy to rework along these lines.
I may have confused people - but I too think it is OK to express this as one property. I think there are subtle differences, but such details are not important to TAPS. (Any app needing finer control will likely need to control more than this).
this alternative is in
Very nice! Thanks a lot for doing this!