Draft: draft-ietf-taps-interface

Commentary: of the API Draft states : 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. , should n'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 do n't think we should spec it using the Preference type though ( seems like a bit of a hack : a " Preference " is n't what this is , and the re - interpretation of Avoid and Prefer is n'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 is n'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 We should make the inheritance of properties from connection - wide preferences onto messages more clear . 
 Suggestion : In 9.1.3 , explain that if you do n't set a specific property on a message , the connection / selections properties apply based on what the connection has , and the ones that do n'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 .
Paragraph (version A):
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
do not have any effect on this Send call.
Paragraph (version B):
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
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
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).
Paragraph (version B):
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).  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.