Change:
Enumeration <ins> inherited from the Connection Property "connCapacityProfile" (prop-cap-profile) </ins> This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of the Capacity Profile connection property (see prop-cap-profile).

Discussion:
I'm not 100% sure, but I believe the DF bit applies only to intermediate hops, not to the originating machine. E.g., if you have DONTFRAG set on your socket (or at the system level via pmtud) and shove 60K into a sendto() call, the kernel will still happily chop your datagram into multiple <=1500 octet packets. So, the text in §8.1.3.9 is probably misleading.
I'm not sure if this makes the text misleading? The text only says that "a message should be sent and received as a single packet without network-layer fragmentation, if possible." It may not be possible... there's also this sentence: "When used with transports supporting this functionality and running over IP version 4, the Don't Fragment bit will be set." - consider the first half of the sentence: the functionality is constrained to being offered only over transports that provide this precise functionality.
I think the text is literally correct, but misleading in that it implies a level of actionability that doesn't appear to be in evidence. Unless you have a means to know path MTU, you can't adjust your message length to avoid fragmentation or drop, so what good does this do other than result in drops vs. path fragmentation in IPv4? This will have zero effect on IPv6, for instance.
I'm confused about the confusion. What is being asked?
I think I'm asking for an example of where this property would make a difference to the wire image, other than in the DF-set case on IPv4 where intermediate hops will drop rather than fragment.
I think that this is really mainly about DF / IPv4. But, if you think of a protocol like SCTP which stuffs messages into packets, this protocol could theoretically decide that message X should not be placed such that the first half of it goes into packet 1 and the next half into packet 2, but that packet 1 should just be shorter and the whole message X should go into packet 2 instead. This is transport-layer fragmentation, not network-layer fragmentation, though. Perhaps "network-layer" should be removed from the text? This should be safe to do as long as we don't make any promises.
I don't think we should conflate transport segmentation of data with network-layer fragmentation. These have different purposes.

A source host still has the choice to fragment at the network-layer to the PMTU, by the way, even when DF is set - as in IPv6. Protocols like STUN might use this to control which packets are sent with fragmentation at the sender to the PMTU, and which carry control packets to probe for a larger PMTU.
Sure the host can at the network layer anyway; we're not giving any guarantees against that. Fine not to conflate - but then the semantics of the text in §8.1.3.9 really only translates into: "in case of IPv4, DF=1". I think this is fine - it seems Kyle wants more, but why? Or should the text more bluntly say "IPv4 DF=1" perhaps?
Michael, that's basically what I'm arguing. The only lever TAPS has is over intermediate hop behavior on IPv4, reducing the whole property to "sets DF=1 on IPv4". I also agree with Gorry re: segmentation vs. fragmentation. Do we need text re: segmentation for protocols like SCTP and QUIC?
The minset part for the transport layer thing is called "request not to bundle messages"; the minset appendix currently identifies that the "No Fragmentation" message property conflates this with network layer fragmentation. I suggest that I'll fix this, by: changing the "No Fragmentation" text a little bit, just to more bluntly state that this is really only about IPv4 DF adding a Message Property that has just the transport-layer "request not to bundle messages" semantics. That should do the trick, I believe.
Shouldn't the default value for every message property basically be "inherit", i.e., from the connection? : This is a bit awkwardly worded. If this is supported for both reliable and unreliable transports (unclear?), then: For reliable transports, this means that this message will not be delivered to the application until all previous ordered messages on the connection are delivered. For unreliable transports, this means that any message prior to this one in ordering but received subsequently will not be delivered to the application.
Multiple things here. Default: interesting idea, I tend to say "yes". About §8.1.3.3: This is meant to support both reliable and unreliable transports - why this unclear (why wouldn't it support both)?

IIRC this was me, borrowing the wording from SCTP which also covers both of these cases (reliable and unreliable). I like your description (at least the one for reliable transports), but I think it's good to be explicit about the relationship to the Send Action. How about this, maybe simpler to read and still generic:
URL be preserved on delivery via Receive<> events for all Messages... ?
We got us a deal! :-) Seriously, this is better and clearer, thanks! Will fix
Seeing the number of this issue, it's clear to me that you chose the wrong issue when you wrote "For the love of Satan".
Just a note regarding : you said that the default for every message property should basically be "inherit"; checking them carefully one by one showed me that this is only a reasonable decision for three of them: Ordered, Reliable Data Transfer (Message) and Message Capacity Profile Override. E.g., a default of using less than a full checksum doesn't and probably shouldn't exist anywhere. Any default other than "False" for "Final" (last Message of the connection) really doesn't make a lot of sense (only the application would know that it has only one Message to send). ... and so forth.
You are technically correct, which is the best kind of correct. I basically meant that message properties that are used to override the same property at the connection level should default to "inherit".
Looks like these issues have been addressed in this PR