Change:
of the API Draft states: At this point, the reader gains the impression that is created independently of any Connection/Selection Properties. However, goes on to state: This raises numerous questions: Does this mean that Selection Properties have to be "in scope" whenever a object is created? (i.e., shouldn't take the current Selection Properties as an argument?) How does, a Selection Property of, e.g., even meaningfully map to a Boolean? (i.e., why is the Property Type a Boolean instead of a Preference?) (Note that the property from raises similar questions)
That's a great catch, thanks! I agree that it should be possible to create a messageContext independent of Connection/Selection properties. A static default may be bad: one may e.g. always have msgOrdered=true, not care about it, and never be able to benefit from a Connection that can do msgOrdered=false. So, instead, I'm tempted to suggest that the default will be assigned (unless the value has been specifically assigned with "add" as in your example above) based on Connection/Selection properties upon use - during the Send call. But this also easily gets bad: it would be an easy mistake to miss this in a TAPS Transport System implementation, and ... if I want to read the value of this parameter of the messageContext, what do I get? Maybe we could define a new special value: "to be updated upon use" ? Tricky. Ideas, anyone?
In my implementation, I've tentatively changed the Type to the enum Type This has a number of advantages: The default value of , which the spec defines as "no preference" unambiguously stands for "simply inherit this Property from the connection properties when sending this message" and are equivalent to the semantics from the spec The possible values of and are essentially equivalent to and , but are understood to not generate errors, even if the underlying connection has no support for the desired Property Note that this setup alone does not allow the Object to "query" a default value for this Property from other contexts. It is not quite clear to me why this would ever be needed in practice.
Interesting! I don't think we should spec it using the Preference type though (seems like a bit of a hack: a "Preference" isn't what this is, and the re-interpretation of Avoid and Prefer isn't too nice either... but that's ok for an implementation!). We could have the type definition as follows: Type: Boolean or (this is similar in style to the type definitions in e.g. 8.1.4, 8.1.8, 8.1.9) Default: ... and we could explain that here means to inherit the value from the connection properties when sending this message. As for querying a default value, I agree that this isn't something one would need in practice but I wanted to be consistent here (everything can be queried as far as I understand) - anyway, querying without changing anything should yield the value , so that's ok, then. If folks agree with this, I can make a PR.
I guess making this inheritance mechanism more obvious could really help here. But using "ignore" for "inherit" or "default" is a bad choice, though. When designing this, we rather thought the message context to be something like a dictionary, where we put all "changes" we want to apply to the message, but making it somewhat of a strongly typed object may require constructing it from the connection in order to derive the defaults.
Agreed with NAME We should make the inheritance of properties from connection-wide preferences onto messages more clear.
Suggestion: In 9.1.3, explain that if you don't set a specific property on a message, the connection/selections properties apply based on what the connection has, and the ones that don't inherit from a connection just use their default.
[Note to self] ... and additionally put specific text about this in the description of the properties where the default is described as "inheriting" from the Connection.

Discussion:
Properties can be added to a MessageContext object only before the context is used for sending.  Once a MessageContext has been used with a Send call, further modifications to the MessageContext object <del> do not have any effect on this Send call. </del> <ins> do not have any effect on this Send call.  Message Properties that are not added to a MessageContext object before using the context for sending will either take a specific default value or be configured based on Selection or Connection Properties of the Connection that is associated with the Send call.  This initialization behavior is defined per Message Property below. </ins> The Message Properties could be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given

allow out-of-order delivery for certain messages, e.g., by multiplexing independent messages onto different streams. <ins> If it is not configured by the application before sending, this property's default value will be based on the Selection Property "preserveOrder" of the Connection associated with the Send Action. </ins> 9.1.3.4. safelyReplayable

may disable retransmissions or other reliability mechanisms for this particular Message, but such disabling is not guaranteed. <ins> If it is not configured by the application before sending, this property's default value will be based on the Selection Property "reliability" of the Connection associated with the Send Action. </ins> 9.1.3.8. msgCapacityProfile

This enumerated property specifies the application's preferred tradeoffs for sending this Message; it is a per-Message override of <del> the Capacity Profile connection property (see prop-cap-profile). </del> <ins> the Capacity Profile connection property (see prop-cap-profile).  If it is not configured by the application before sending, this property's default value will be based on the Connection Property "connCapacityProfile" of the Connection associated with the Send Action. </ins> 9.1.3.9.