Issues for Notification Services RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1423: Add destroy operations
Issue 1424: Fix existing bug in CosTypedNotifyChannelAdmin IDL
Issue 1425: Define new Service ID
Issue 1426: Make section 2.10 consistent with current CORBA 2.1
Issue 1427: Clean up description of QoS properties
Issue 1499: Error in Event Type Repos IDL in Notification
Issue 1524: <CompEsc> lexical token issue
Issue 1580: We need default value for DiscardPolicy
Issue 1584: Reference to MaxQueueLength--QoS issue for Notification
Issue 1618: subscription_change issue
Issue 1638: Filter grammar problem
Issue 1660: No way to "quench" to event style supplier
Issue 1680: Use of lexical components
Issue 1681: Syntactic category <Factor> includes <Ident> and \<Ident>...Why?
Issue 1682: Section 2.4.6 : positional notation wrt to unions
Issue 1684: Constraint Language issue
Issue 1706: comment_*() operations needed in CosNotifyComm Interface
Issue 1773: No way to "quench" typed event style clients...
Issue 1774: ProxyConsumer and ProxySupplier need readonly attributes to identify type.
Issue 1791: Move name up to PropertyErorr and create a NamedPropertyRange struct
Issue 1792: Remove the use of CosTrading property types
Issue 1793: Dependance on CosTrading
Issue 2008: Removal of explicit Transactional interfaces
Issue 2113: Editorial issue
Issue 2114: Cardinalities for "imports" and "inherits" wrong
Issue 2120: Suspension of connections
Issue 2121: Another issue related to suspend/resume connection
Issue 2157: .Clarification of pull_structured_events definition
Issue 2203: Notification Constraint language problem
Issue 2211: The term name-value pair is not well defined
Issue 2212: Footnote on page 34
Issue 2213: The section 2.4.5
Issue 2216: Issue with the algorithm for evaluating $<variable> expressions
Issue 2217: Not all references to event types have been updated
Issue 2219: Text on p. 54 describing applicability of EvenReliability QoS out of date
Issue 2220: Explicit statement missing in contraint grammar
Issue 2229: Inconsistency on p 54
Issue 2297: Unnecessary restriction defined on Mapping Filters
Issue 2433: CosNotification -- MaxEventsPerConsumer = 0 for infinity?
Issue 2434: Default values for PacingInterval and MaximumBatchSize QoS properties?
Issue 2448: EventType IDL typos
Issue 2554: Filter evaluation in pull mode
Issue 2555: Semantics of Disconnected exception
Issue 2652: Modify the DiscardPolicy text, paragraph 1 page 56
Issue 2653: To add to "Reliablity" text, Page 54 after paragraph 3.
Issue 2654: Modify RejectNewEvents description, paragraph 8 page 56
Issue 2655: Modify paragraph 6, page 52
Issue 2662: CosNotifyChannelAdmin module: typed proxies not defined in ProxyType enum
Issue 2712: TimeBase::UtcT where TimeBase::TimeT is needed
Issue 2713: Pull Methods on Sequence Suppliers
Issue 2714: Problem with Sequence Pull Model
Issue 2740: Clarify Handling of Priority and Timeout
Issue 2743: Semantics of Timeout Value

Issue 1423: Add destroy operations (notif_service-rtf)

Summary: 1) We should add "destroy" operations for the ConsumerAdmin and
    SupplierAdmin interfaces defined in CosNotifyChannelAdmin
 

Summary: 2) We need to fix the existing bug in the CosTypedNotifyChannelAdmin
    IDL, caused by the TypedEventChannel interface defined there inheriting
    from both CosNotifyChannelAdmin::EventChannel, and 
    CosTypedEventChannelAdmin::TypedEventChannel. Because the former
    also inherits CosEventChannelAdmin::EventChannel, 
    CosTypedNotifyChannelAdmin::TypedEventChannel is inheriting from
    multiple interfaces that each define "for_consumers" and "for_suppliers"
    operations, returning values that are scoped differently. This is an
    IDL bug that must be resolved.
 

Summary: 3) We need to define a new Service ID that can be returned by 
    "resolve_initial_references" for the factory for typed notification 
    channels
 

Summary: 4) In section 2.10 we describe how to modify CORBA 2.1 in order to
    accommodate our new ID (should be IDs, see #3) that can be
    returned by "resolve_initial_references". There, we list 
    "NamingService" as one of the valid IDs. But in CORBA 2.1, this is
    currently "NameService". We should section 2.10 consistent with the
    current CORBA 2.1 in this way.
 

Summary: 5) In general we need to clean up the description of QoS properties to
    clearly distinguish which properties are valid in the optional header
    field of a structured event, and which can be set on proxies, admins,
    or channels. Certain properties only make sense on a per-message basis,
    and others make no sense on a per-message basis. Currently the spec is
    very unclear on this distinction, and we should fix this.
 

Summary: someone looking at the event type repository IDL in the Notification
 Service Spec has found a bug in the generated IDL from the MOF model:
 
 > 3. In EventTypeRepositoryClass.create_event_type_repository,
 >    why is the parameter a string and not a StringSet?
 
 You are correct. It"s should be StringSet. There was a bug in the
 prototype that generated the IDL used in the Event Notification.
 
 

Summary: The <CompEsc> lexical token for the default constraint grammar is 
 inadvertantly not defined along with the other newly introduced lexical
 token. A definition of this token should be added where the other new
 tokens are defined.
 

 Add definition of CompEsc to section 2.4.

Summary: In the spec we define the DiscardPolicy QoS property, and the various
 settings it can take on. But, we don"t define what the behavior is
 when the property is not set, and we don"t define a value of NONE that
 can be used to disable the DiscardPolicy after it has been set.
 My proposal is to define a new value, say NoOrder, which is the default
 value and means that DiscardPolicy is disabled, so attempts to send events
 to the channel when the buffer is full will fail, rather than have events
 already in the buffer be discarded.
 
 As a related issue, we may also want to define a DiscardInterval, so that
 if DiscardPolicy does kick in, the algorithm can select more than one
 event from the buffer to discard. This would prevent the channel from 
 thrashing between executing its discard algorithm, and receiving new events.
 I"d be interested in comments about this idea, in addition to the proposal
 to define the NoOrder value for DiscardPolicy.
 

Summary: I cannot seem to find any refernce to MaxQueueLength
 other than in IDL and there is no comment in the IDL explaining this
 parameter.  This whole area seems to be under-specified. It is certainly
 not in the "Discard Policy" section where it should be.
 

  Through discussion of this issue, it was agreed that the 

Summary: The text describing the behaviour of implementations calling
 subscription_change on their suppliers:
 
 Suppliers that are not interested in the event types currently
 subscribed to will not invoke obtain_subscription_types, and will
 raise the NO_IMPLEMENT exception in their implementation of the
 subscription_change operation.
 
 The mechanism (raising NO_IMPLEMENT) is crude, and the continuing
 behaviour of the channel is unspecified; i.e. should the channel
 always call subscription_change and just put up with the exception? I
 should think not. However, should the channel assume that this
 supplier will never be interested in subscriptions ever again? Perhaps
 not. What if the supplier raises NO_IMPLEMENT, and then later calls
 obtain_subscription_types - does this indicate that it is now
 interested in subscription changes?
 

Summary: The nonterminal symbol <CompEsc> is undefined on page 50.
 
 I suspect it should simply be a terminal "\" (consistent with the use
 of "+", "-" and "\\" in other parts of the grammar.
 

Summary: In the CosNotifyComm module, we define new client interfaces for clients
 that supply and consumer structured events and sequence of structured events.
 In the CosNotifyChannelAdmin module, we define different proxy interfaces
 for clients that deal with Anys, structured events, and sequences of
 structured events. For the proxies that deal with Anys, we rely on 
 Event tyle clients to connect to them. In other words, the input parameter
 to the "connect_*" operations defined on the proxies provided for clients
 that deal with Anys are of a type defined in the CosEventComm module. This
 is because we don"t redefine Notification-specific interfaces for clients
 that deal with Anys.
 
 It has just occurred to us that this makes it impossible to propagate 
 "subscription_change" requests to clients that deal with Anys. This is
 because such clients are defined in CosEventComm, and do not support
 the NotifySubscribe or NotifyPublish interfaces.
 

Summary: Firstly, due to the use of lexical components such as "and", "or",
 "not", etc., the grammar is not context free. A backslash (I assume the
 syntactic category <CompEsc> is a backslash) is used to distinguish
 runtime variables from symbol names, and this is enough to ensure that
 any symbol subsequent to "\" is treated as an <Ident>.
 
 However, the <CompDot> lexical category doesn"t provide for an escaped
 <Ident>. However, I believe the following is legal IDL:
 
 struct A {
     long and;
 };
 
 This leads to a situation where a constraint such as:
 
 $.A.and == 34
 
 must be regarded as syntactically incorrect for the grammar to remain
 context free.
 
 I believe that the issue can be resolved without ambiguity by extending
 <CompDot> to allow a backslash followed by a <CompIdent>.
 

Summary: Secondly, I"d like to have something clarified, if possible. The
 syntactic category <Factor> includes <Ident> and \ <Ident>. What is the
 reason for this? It seems to me that the only use for <Ident> in this
 context is as a check for the existence of a runtime variable. $var is
 used to denote the value of runtime variable var. However the "exist"
 operator is used for this.
 
 Would the semantics be any clearer if "$" was not used for runtime
 variables at all? In this case a standalone <Ident> (not part of the
 current event) would denote a variable.

Summary: In section 2.4.6 of the Notification Spec, there"s a discussion about
 positional notation wrt to unions. Examples are given using the
 constraints of the form $.(nn). e.g.,
 $.(3).2 < 128
 
 However, this isn"t syntactically correct. the Compdot syntactic
 category is given as:
 
 <CompDot> := <CompIdent> | <CompPos> | ** the "_" literals **
 
 <CompIdent> must begin with an <Ident> which must begin with an
 aphabetic char.
 <CompPos> must begin with a digit.
 
 <Component> may be empty, in which case an operator like +,-, and, or,
 etc will be expected, but not a "(".
 The same mistake is made throughout Section 2.4.6, in the fifth,
 sixth, and seventh paragraphs. There are also some comments such as "
 .. using run time variables as "$(3).2 < 128" .." in the fifth
 paragraph that don"t make sense. (That example is wrong because a
 runtime variables must be introduced by $<Ident>.) 
 

Summary: Because the constraint language is inherited from the Trader specification, we
 have these categories:
 
 <expr_in> := <expr_twiddle> in <Ident> | <expr_twiddle>
 <expr_twiddle> := <expr> ~ <expr> | <expr>
 
 It seems that the point of the "in" operator is to determine whether the LHE
 is in the RHE where the RHE is a sequence. However, there"s no way to access
 the current event since the RHE is only allowed to be an Ident, not "$"
 <Component>. It appears that the RHE could only be an unstructured runtime
 variable in practice. If this is not the case, how is it supposed to work?
 
 In addition, the <preference> syntactic category makes no sense. I assume that
 it is not be supported. This is perhaps a small point, but I can"t find a
 reference to it.
 

Summary: One of the missing pieces in the Notification Service is that
 connect_*() operations are needed on the CosNotifyComm interfaces.  That
 way a third party can connect the end points and channel together.  With
 the current spec the end points have to connect them self to the channel
 or a third party needs to know the proprietary extensions of the
 endpoint to set up the connection.  The endpoints that ALWAYS connect
 themself to the channel could throw the NO_IMPLEMENT exception.
 
 
 

Summary: Similar to the problem described in Issue 1660 for Any-style clients,
 there is no way to pass quench or offer information to typed event style
 clients. This is because typed event style clients are either defined
 in CosEventComm or CosTypedEventComm, depending on the client type, and
 these interfaces do not inherit NotifyPublish or NotifySubscribe.
 
 

Summary: Currently it is possible to obtain a list of all ProxyConsumers being
 managed by a SupplierAdmin, and a list of all ProxySuppliers being managed
 by a ConsumerAdmin. But, given an entry on either one of these lists,
 the only way to determine its actual type is to try narrowing it to the
 Any, Structured, or Sequence version of the Proxy. If the ProxyConsumer
 and ProxySupplier interfaces maintained a readonly attribute that 
 distinguishes each Proxy"s type, however, it would be easier for 
 clients to walk through a list of Proxies obtained by performing 
 a "get" operation on an Admin, and determine which type of Proxy each
 entry is. 
 
 
 

Summary: I have an issue which CORBA Notification specification in the area of
 Properties.
 
 In CosNotification.idl PropertyError the name of the property in error
 is burried the PropertyRange. This seems to have been done for reuse in
 the PropertyRangeSeq. It is confusing and likely to cause error. I
 suggest we move name up to PropertyErorr and create a NamedPropertyRange
 struct. 
 
 

Summary: [the following is raised as a separate issue] Lets remove the use of CosTrading property types.
 This is an unnecessary dependancy for such simple types.
 

Summary: We re-use the type CosTrading::PropertySeq in the Notification IDL,
 and this is the only this that"s re-used from this module. The result
 is that code in C++ and Java implementing the entire CosTrading IDL
 stubs in linked or loaded into a running Notification Service. This
 creates an unacceptable bloat for such a trivial re-use.
 
 

Summary: As a result of the deprecation of the TransactionalObject interface 
 defined by the recently adopted CORBA Messaging specification, it is no
 longer necessary for the Notification Service to explicitly define 
 transactional client and proxy interfaces. Instead, descriptive text should
 be added to Chapter 2 explaining how an implementation of Notification
 should support transactional event tranmission.
 
 

Summary: QoSAdmin::get_qos and QoSAdmin::set_qos are spelled get_QoS and set_QoS in
 paras 3.1.4.1 and 3.1.4.2.
 

Summary: The UML diagram in appendix A of the Notification Service has the
 cardinalities for "imports" and "inherits" associations the wrong way
 around. This makes it inconsistent with the description text and MODL.
 
 Proposed resolution: The "imports" association should be [0..*] to
 [0..*], and "inherits" should be 1 to [0..*].
 

Summary: This issue relates to the ability provided in Notification Service
 ProxyPushSuppliers for a consumer to suspend a connection to the channel
 (stop the channel pushing events to it) which is unavailable to the
 other passive clients of the service - pull suppliers. 
 
 The problem arises because, without the ability for a pull supplier to
 suspend a connection, its only choices are 
 
     (a) to block the return of a pull() call until it is able to
 	supply an event - resulting in some ORB-dependent timeout on
 	the call, or a blocked thread in the channel.
 
     (b) to reply to many unnecessary try_pull() calls with a FALSE
 	result - expecting that the channel will use some sort of
 	backoff algorithm.
 
     (c) to disconnect from the proxy and obtain a new one when it is
 	ready to supply events again  - causing significant overhead
 	for both itself and the channel.
 I suspect that we only provided one set of suspend/resume operations
 because the only circumatance we considered in the design was data
 overrun at consumer clients. We ignored the traditional symmetry, and
 neglected "under-run" and its less disasterous, but still significant
 problems.
 
 

Summary: I would like to register another issue related to suspend_connection
 and resume_connection. I feel a new exception should be defined for each
 of these operations, to cover the case in which a client invokes one
 of these operations on a Proxy which has not yet been connected to by
 a client. Currently, it is possible for a client to invoke one of these
 operations on a Proxy that is not connected to a client, but there is
 no appropriate exception to raise.

Summary: Section 3.3.13.1 pull_structured_events
 
 "...the amount of time a supplier will accumulate events into the sequence
 before transmitting it...are controlled bu QoS property settings as described
 in section 2.5.5."
 
 Followed in the next paragraph by:
 
 "...Note that the operation will block until there is a sequence available
 to return."
 
 Proposed resolution:
 
 The final sentence quoted should read:
 
 " Note that the operation will block until there is a sequence available
 to return unless overridden by QoS pacing policies."
 
 Alternatively the final sentence could be deleted..
 
 

Summary: Section 2.4.3 (final bullet) says:
 
     * When a boolean operand is used in an arithmetic operation, it is
 	treated as weakly-typed CORBA::Long.
 
 This is semantically very dubious. What value is used for TRUE and
 FALSE? 1 and 0 perhaps? This results in "TRUE + TRUE == 2" producing a
 match and "TRUE / FALSE" producing a divide by zero error!
 

Synopsis: DSTC questioned the final bullet in section 2.4.3 which states that,

          with respect to the constraint grammar, boolean values are treated

          as weakly typed CORBA::Longs when used in arithmetic operations.

          In their message raising this issue, DSTC complained that this is

          semantically weak, although they added that some members of DSTC

          actually like this feature.



          DSTC proposed two alternative solutions to this issues:



          1) Get rid of the feature by changing the bullet to state that usage

             of boolean values in an arithmetic operation is a type mismatch

             error, causing whatever "match" operation within which they are 

             used to fail



          2) Clarify that the value of TRUE and FALSE, when used in arithmetic

             operations, correspond to 1 and 0 respectively



Disposition: We at NEC like this feature, and feel it is both required and

             standard with the way CORBA treats boolean values. We feel it's

             required because it allows the constraint grammar to handle

             expressions that combine the results of boolean comparisons, 

             which we feel is typically expected of a constraint grammar

             (e.g., ($.fruit = apples) + ($.color = red) + 

                ($.kind = macintosh) > 2)



             Furthermore, while we have no fundamental opposition to explicitly

             stating that TRUE=1 and FALSE=0, we don't necessarily feel it's

             necessary because section 12.3.1 of CORBA alread states that 

             "Boolean values are encoded as single octets, where TRUE is the

             value 1, and FALSE is 0." Essentially, we feel CORBA already 

             defines TRUE to be 1 and FALSE to be 0, however we are not 

             opposed to adding such a statement into Notification if folks 

             feel it's necessary.



VOTE: This vote is being subdivided into 2203a and 2203b. Voting YES on

      2203a means to accept option 1) described above. Voting YES on

      2203b means to accept option 2) described above. Voting NO means to

      do nothing. It is invalid to vote YES on both 2203a and 2203b.



NOTE: Only 2203b passed

Summary: 1) The term name-value pair is not well defined in the Notification
 document. 
 
 Suggested resolution:
 
 We need to decide as a group to explicitly state that either only
 CosNotification::PropertySeq is supported (as well as structutally
 equivalent types only when IIOP messages elide member naming or IR
 info), OR that any structurally equivalent type is supported.
 I would favour the former - as it allows implementers to rely on the
 TypeCode::equal() operation to do comparisons portably rather
 than doing explicit traversals of the typecode.
 

Synopsis: DSTC feels that the term "name-value pair" is used too freely 

          throughout the spec without a clear definition of what's meant by

          it. They suggested that we should either explicitly state that 

          either CosNotification::PropertySeq must be used wherever a

          name-value pair is called for (except where IIOP messages elide

          member naming or IR info, in which case structurally equivalent types

          may be used instead), or that any structurally equivalent type can

          always be substituted for a CosNotification::PropertySeq. DSTC

          mentioned that their preference is the former, as it allows for 

          explicit, portable type comparisons rather than requiring typecode

          traversal to do type checking.



Disposition: I have no objection to DSTC's first proposed resolution,

             except that I do not understand the parenthetical part, which

             I abstracted from DSTC's original mail describing the issue to

             make sure it wasn't dropped, even though I don't understand it.

             Essentially, I feel DSTC wants Notification to explicitly state

             the name-value pairs used throughout Notification must always 

             be the data type CosNotification::PropertySeq, and not some 

             structural equivalent, except in one exception case which I'm not

             quite clear about. Once DSTC clarifies this last part, I would 

             be happy to incorporate the suggested change.



VOTE: YES means to add text clarifying that name-value pairs in Notification

      are always of type CosNotification::PropertySeq; NO means to do nothing

Summary: 2) I note that a footnote on page 34 of the spec says that the term
 "name-value pair" is not meant to denote CORBA::NVList, but it doesn"t
 actually say what it does mean. This should be fixed too (before table
 2.2 where it"s used first).
 

Synopsis: This issue is related to issue 2211. There is currently a footnote 

          on the bottom of page 34 which states that the term "name-value 

          pair", as used thoroughout Notification, should not be construed to

          mean CORBA::NVList. However, the footnote does not clearly state

          what "name-value pair" does mean. The proposed resolution is to add

          text to the footnote to clarify that "name-value pair" means

          CosNotification::PropertySeq



Disposition: I agree with the issue and the proposed resolution.



VOTE: YES means to add the recommended text to the footnote; NO means to do

      nothing

Summary: 3) The section  2.4.5 - "A Short-hand Notation for Filtering
 a Generic Event" is supposed to provide a way of addressing all event
 types, IMO including typed event transmissions that appear within an
 Any as a CosNotification::PropertySeq with properties for the
 operation name and each parameter.
 Some text should be included which states that $<ident> matches not
 only $.<ident> for anys, but also $(<ident>) in the case where the any
 contains a single CosNotification::PropertySeq.
 

Synopsis: It was pointed out that the short-hand notation for filtering 

          generic events described in section 2.4.5 does not clearly

          indicate the notation can be used to designate typed events

          that have been wrapped into an Any as a CosNotification::PropertySeq.

          It was proposed to add text to this section to indicate that 

          $<ident> matches not only $.<ident> for Anys, but also $(<ident>)

          in the case the Any contains a single CosNotification::PropertySeq.



Disposition: I agree with the issue and proposed resolution. Specifically,

             I propose to modify the last sentence of the 4th paragraph

             of section 2.4.5 to read:



             "If no match is found, the translation defaults to either

             $.variable, or in the case of a CORBA::Any that encapsulates

              a single unnamed name-value pair list (Sec 2.4.4), $(variable)."



VOTE: YES means to add the proposed text; NO means to do nothing

Summary: The algorithm for evaluating $<variable> expressions does not
     allow for $domain_name and $type_name to be used.
 

Synopsis: Section 2.4.5 describes an algorithm for evaluationg $<variable>

          expressions. As currently stated, the algorithm would not allow

          for $domain_name and $type_name to be used, since the text states

          that it can only be applied to resolve simple-typed members of

          $.header.fixed_header, when in fact the domain_name and type_name

          members of the fixed header are nested within the EventType

          structure, and are therefore non-simple-typed members. The proposed

          resolution is to re-word the relevant text to state the the

          algorithm can resolve $domain_name, $type_name, and $event_name to

          $.header.fixed_header.event_type.domain_name,  

          $.header.fixed_header.event_type.type_name, and

          $.header.fixed_header.event_name, respectively. 



Disposition: I agree with the issue and the proposed resolution. The current

             text is legacy from before the fields in question were made part

             of a complex data type.



VOTE: YES means to re-word the text as recommended; NO means to do nothing

Summary: Not all references to event types have been updated to refer to
 the correct IDL type names:
 
 struct EventType {
 	string domain_name;
 	string type_name;
 };
 

Synopsis: An older, pre-adoption revision of the spec defined the fixed header

          of a structured event to contain string type members named 

          "domain_type" and "event_type". Prior to adoption of the spec, this

          was changed to be the following data structure



                struct EventType {

                        string domain_name;

                        string type_name;

                };



          The submitter of this issue pointed out several places in the

          spec where the legacy fixed header member names "domain_type"

          and "event_type" are still used, and recommends they be changed

          to make them consistent with the actual member names.



Disposition: I agree with the issue and the proposed resolution



VOTE: YES means to make the recommended changes; NO means to do nothing

Summary: The text on page 54 describing the applicability of EventReliability
 QoS is out of date:
 
 	"Note that the QoS properties related to reliability can be
 	set at the channel, group, and proxy levels, but not on an
 	individual event basis."
 

Synopsis: There is text on page 54 that states that the EventReliability

          QoS property can be applied per-Channel, per-Admin, and per-Proxy

          but not per-event. Elsewhere in the spec, it claims EventReliability

          can be applied per-Channel and per-event. The proposed resolution

          is to change the text on page 54 to make it consistent with the

          rest of the spec.



Disposition: I agree with the issue and the proposed resolution



VOTE: YES means to make the recommended change; NO means to do nothing

Summary: Issue: No explicit statement is given in the contraint grammar about
 which operators apply to enumerated types.
 
 Suggested solution:
 
 Only equality and inequality operators (== != >= > < <=) should be
 defined as legal on enums... as these are all that CORBA requires are
 available in a language mapping.
 

Synopsis: No explicit statement is made in the description of the constraint

          grammar about which operators can be applied to enumerated types.

          The proposed resolution is to add text stating that only 

          equality and inequality (== != >= <= > <) can be applied to enums.



Disposition: I agree with the issue and the proposed resolution



VOTE: YES means to add the recommended text; NO means to do nothing

Summary: Just a minor note to page 54 in the 98-11-01 spec. In the last paragraph
 of the Reliability section, you say that EventReliability can be set
 both at channel, admin and group level. This is inconsistent with Table
 2-4. If the table is correct you should probably remove that last
 paragraph completely as I think it makes sense to set
 ConnectionReliability at any level.
 

Synopsis: This issue points out text on page 54 that claims the EventReliablity

          QoS property can be applied to an EventChannel, Admin, or Proxy.

          Table 2-4 which summarizes which QoS properties apply to which

          objects indicates EventReliability can be applied to an EventChannel,

          or on a per-message basis. The proposed resolution is to modify the

          text to make it consistent with the table.

 

Disposition: I agree with the issue and the proposed resolution



VOTE: YES means to make the recommended change; NO means to do nothing

Summary: The sections in Chapter 3 that discuss the semantics of priority_filter and
 lifetime_filter associated with Proxy objects indicate that Mapping Filters
 associated with Proxy objects are only applied if there is no equivalent
 Mapping Filter defined for the Admin that created the Proxy. If there
 is a Mapping Filter defined at the Admin level, the one defined at the
 Proxy level is ignored.
 
 We feel this restriction is unnecessary, and in some cases even undesirable.
 We thus feel the text that indicates this semantic should be removed wherever
 it appears.
 

Synopsis: The sections in Chapter 3 that discuss the semantics of 

          priority_filter and lifetime_filter associated with Proxy objects

          indicate that Mapping Filters associated with Proxy objects are

          only applied if there is no equivalent Mapping Filter defined

          for the Admin that created the Proxy. If there is a Mapping

          Filter defined at the Admin level, the one defined at the Proxy

          level is ignored. We (NEC) feel this restriction is unnecessary,

          and in some cases undesirable, as it may be desirable to define

          a Mapping Filter at the Proxy level which overrides that set at

          the Admin level. Our proposed resolution is to remove the text

          that states this restriction.



Addendum: This issue was re-raised recently. The current consensus seems to

          be that the text should explicitly say that the MappingFilter at

          the Proxy level overrides on set at the Admin level.



Disposition: I agree with the issue and the proposed resolution described in

             the addendum.



VOTE: YES means to change the text according to the addendum. NO means to do

      nothing.

Summary: The CosNotification spec is careful to say that, for the administrative
 properties (MaxQueueLength, MaxConsumers and MaxSuppliers), the default 
 value is zero, and it means that there is no limit.
 
 As far as I can see there is not similar wording for the QoS property
 MaxEventsPerConsumer.  Two questions that should probably be answered are:
 
       -	is there a magic value that means "no limit"?
 
       -	what is the default value if it"s not eqplicitly set at any level?
 
 I would suggest that, for consistency with MaxQueueLength, the magic value
 should be 0, and the default should be that same value.
 

Synopsis: The spec states that a 0 value for MaxQueueLength, MaxConsumers

          and MaxSuppliers means those QoS properties impose no limited on

          the entity they are intended to constrain. The is not similar

          wording for MaxEventsPerConsumer. The proposed resolution is to

          add similar wording for MaxEventsPerConsumer, making 0 be the

          default value meaning there is no limit on the number of events

          that can be queued per consumer.

  

Disposition: I agree with the issue and the proposed resolution



VOTE: YES means to add the recommended text; NO means to do nothing

Summary: Are there any default values for the PacingInterval and MaximumBatchSize QoS
 properties? The default value for PacingInterval could be 0 meaning that a
 sequence type consumer is willing to wait indefinitely for an event sequence.
 But the MaximumBatchSize can"t be 0 as both zero and an indefinite number of
 events are infeasible (an exception could be raised if this QoS is set to a
 value less than 1).
 

Synopsis: The spec does not define what the default values for PacingInterval

          and MaximumBatchSize are. Furthermore, the meaning of 0 for those

          properties is unclear. The proposed resolution is to make 0 be

          the default for PacingInterval, and have it mean that the client

          is willing to wait indefinitely for the batch to fill up, but

          the author of the issue was not sure how to handle the default

          value and meaning of 0 for MaximumBatchSize.



Disposition: I agree that the default value for PacingInterval should be 0,

             and that it should mean the Proxy on which it is set will never

             forward a "partial" batch, instead waiting for MaximumBatchSize

             events to accumulate before forwarding the any batch. As for

             MaximumBatchSize, I propose that the default value be 1, for

             lack of a better default value (really, the user should always

             explicitly set this property if using sequence proxies).

             Furthermore, I feel (like the author of the issue) that an attempt

             to set MaximumBatchSize to 0 should cause the UnsupportedQoS 

             (BAD_VALUE) exception to be raised.



VOTE: YES means to make the changes described above in the "Disposition"

      section; NO means to do nothing

Summary: The Notification Service IDL EventType contains the element domain_name.
 In the text of the specification this is refered to as domain_type on
 pages 28, 29, 33, 37, 79 etc. 
 
 

Synopsis: Essentially, this issue is a duplicate of issue 2217. It points out

          that in several places throughout the spec the fixed header field

          "domain_type" is mentioned, when the field its referring to is

          really named "domain_name" in the IDL.



Disposition: The issue points out obvious typos which should be fixed in the

              next revision.



VOTE: YES means to make the recommended changes; NO means to do nothing

Summary: It is unclear from the spec when filters are evaluated in pull mode. For
 suppliers there"s no problem as the filter is evaluated when the event
 is received. On the consumer side, the filter can either be evaluated
 when the event is entered into an internal queue (i.e. when the supplier
 proxy "receives" the event) or when the consumer decides to pull the
 event.
 
 This is only a problem when a filter constraint contains the $curtime
 reserved run-time variable. Perhaps the most intuitive for a user is
 filter evalution at pull time? However, the implications can be quite
 significant for sequence type consumers when invoking the
 try_pull_structured_events operation. The proxy will have to match all
 required events against the filters - and if there"s not enough events
 all filter results must be discarded.
 

Synopsis: The spec does not currently state when filtering is performed in

          the case of pull-style consumers pulling events from pull-style 

          proxy suppliers. This is mainly an issue when filtering is done 

          based on $curtime. The submitter of this issue recommends that

          filtering be done when the consumer actually invokes "pull", but

          points out that the issue becomes very tricky in the case of

          sequence pull consumers invoking a "try_pull_structured_events".



Disposition: My personal recommendation is that if the spec is going to 

             specify when filtering is performed in the case of pull-style

             proxy suppliers, that it be specified to be done immediately as

             the proxy receives events (and not delay the filtering until the

             consumer invokes "pull" as recommended by the issue submitter).

             The main reason for this is to keep the implementation more

             straightforward. In general, there will be complications using the

             delayed semantic with regard to the "try_pull" varients because

             the results of "try_pull" on the same set of events would be

             variable over time if filtering is delayed until "try_pull" is

             attempted. For instance, "try_pull" may return TRUE if an event

             exist that is being filtered based on $curtime, and the event

             passes the filter when "try_pull" is invoke. Then, the consumer

             would invoke "pull" assuming an event existed, but the "pull"

             could result in the event being filtered based on $curtime. Now,

             the pull consumer would block due to no event being available

             to pull, even though the consumer had intentionally postponed

             doing "pull" until "try_pull" returned TRUE. 



             So, my recommendation would be to specify the semantic such that

             filtering is done only when the proxy supplier first queues the

             event. If this semantic is well-defined, consumers can construct

             their filters accordingly, and be aware of what will happen when

             they specify constraints based on $curtime.



VOTE: YES means to add text to the spec specifying that filtering by pull-style

      ProxySuppliers is performed prior to the proxy queuing the event to make

      it available for pulling (i.e., as soon as the Proxy receives the event).

      NO means to do nothing.

Summary: It would be nice if the spec explicitly stated what happens when a pull
 supplier or push consumer raises the Disconnected exception. One way to
 look at it is that when the client raises Disconnected it no longer
 wants to send or receive any events and it"s basically disconnected
 (i.e. the same as if the disconnect_xx_yy operation was invoked).
 
 I believe this is an issue because the disconnect_xx_yy operation
 controls the lifecycle of the proxy. If the above interpretation is
 valid, the proxy will be destroyed when the client raises Disconnected.
 Alternatively, the proxy could just change its state back to not
 connected (the same state as when the proxy was just created by an admin
 object).
 

ynopsis: The spec does not define specifically what happens when an endpoint

          pull-supplier or push-consumer raises the Disconnected exception.

          The submitter of the issue mentions one interpretation is that

          when an endpoint client raises Disconnected, it no longer wants to

          send/receive events and is basically disconnected. He adds that this

          is an issue because being disconnected has object lifecycle 

          implications for the proxies that the clients are connected to...

          essentially being disconnected implies that the proxies no longer

          exists. So, one possible semantic that could be defined is that the

          proxy that the client is connected to could invoke its own

          disconnect_xx_yy operation to force the proxy to be cleaned up. 

          Another possible semantic, however, is that the proxy could change

          its state back to existing but being not connected, such as it

          was when it was created and prior to the client connecting.



          The submitter of the issue goes on to say that it would be useful

          to specify in what states (i.e., between CONNECTED, NOT_CONNECTED,

          SUSPENDED, and DESTROYED) event type information is propagated

          through the NotifyPublish/NotifySubscribe interfaces.





Disposition: Regarding the main issue, I feel the issue author's first 

             recommendation is correct...the semantic should be that if

             an endpoint raises the "Disconnected" exception during a proxy's

             attempt to send/receive an event, the proxy's disconnect_xx_yy

             method should be invoked to destroy the proxy. As the issue

             author pointed out, the intended semantic of Notification is

             such that when a client disconnects, its proxy should be 

             destroyed. This implies that proxies are not intended to be

             reused by multiple clients. If the proxy is attempting to perform

             event transmission to/from its client, then this implies the 

             client had explicitly connected at some point. If the client

             later on decides it is disconnected, then the proxy should update

             its state to be consistent. This means that the proxy should be

             destroyed.



             And, regarding the second part of the issue, I feel event type

             information should be propagated to a client when its proxy is

             in the CONNECTED or SUSPENDED state. Note that a client can

             turn off event type propagation at any time by invoking the

             obtain_*_types operation on its proxy with an argument of

             ALL_NOW_UPDATES_OFF or NONE_NOW_UPDATES_OFF.



VOTE: YES means to add text specifying that when a client raises the 

      "Disconnected" exception, its proxy's disconnect_xx_yy method is

      automatically invoked to destroy the proxy, and to add text that states

      event type information is propagated to a client in the CONNECTED or

      SUSPENDED state. NO means to do nothing.  

Summary: The description of when and how to apply discard policies is ambiguous.  
 It is unclear whether the discard policy is intended to be applied on 
 the events in their original order or as ordered by an order policy.
 

Synopsis: The issue submitter feels that description of when and how to apply

          discard policy is ambiguous with respect to whether the policy is

          intended to be applied on the events in their original order or as

          ordered by an order policy. The issue submitter proposed the 

          following rewording of paragraph 1 on page 56:



          "This QoS property enables a user of the Notification Service to

          specify in what order the channel should begin discarding events

          in the case of an internal buffer overflow."



          "If a discard policy is set on a channel, it is applied when the 

          total number of events already queued in the channel is equal to

          the MaxQueueLength administrative property (defined in 

          section 2.5.7). If set on a per-ConsumerAdmin basis, the discard

          policy is applied when the number of events queued on behalf of one

          of the consumers exceeds the MaxEventsPerConsumer QoS property for

          that consumer. If set on a per-proxy basis, the discard policy is

          applied whenever the number of events queued on behalf of the 

          connected consumer exceeds the MaxEventsPerConsumer setting for the

          proxy supplier. In the latter two cases, an event is discarded only

          with respect to its scheduled delivery to the consumer(s) on whose

          behalf the policy is being applied. Events queued for delivery to a

          consumer for which the discard policy does not apply are not affected

          and remain queued for that consumer."



          "In all cases, discard policies are applied after the event has been

          received and queued. The RejectNewEvents discard policy is the only

          exception as it is applied before the event is queued."



         In addition, the issue submitter proposed the following rewording

         for the descriptions of the LifeOrder and FifoOrder discard policy

         settings:



         "FifoOrder - The first event in the queue is the first discarded."

         "LifeOrder - The last event in the queue is the first discarded."



        The above is the original proposed resolution, and is now considered

        resolution 2652a. Below are proposed resolutions 2652b and 2652c:



        First, the background for the new proposed resolution:



        There are some issues that appear in connection with the DiscardPolicy

        that are hinted at in the issue (2652) description, but not addressed

        in the text for the resolution. I think we need to seriously consider

        amending the resolution to fix these:



        1) RejectNewEvents not appropriate at any level other than EventChannel



            The RejectNewEvents value of DiscardPolicy is now the _default_

            value. BUT this value is meaningless at Admin and Proxy levels (I

            assume that we don't want the behaviour that setting RejectNew on

            any SupplierProxy results in all ConsumerProxies rejecting push

            calls (or not making any further pull calls) until the

            SupplierProxy's queue has space again - and I can't think of any

            other plausible semantics). Therefore its inheritance as the value

            for created Admins and Proxies is inappropriate. There are several

            ways in which this can be fixed:



        Here are the proposed alternative resolutions. Note that I've 

        relabel them as b) and c), so that the initial proposed resolution

        can be considered resolution a).



        b) [Minimal change model] State somewhere that although this value

                is the default at the Channel, that when Admins and Proxies

                are created the value that they inherit when RejectNewEvents

                is set at the Channel will be Any.



                Note that this is really a quick and dirty fix, as it breaks

                the QoS inheritance model, and (c) provides a more considered

                approach.



        c) [is RejectNew really a DiscardPolicy?] Given that the

                inheritance of DiscardPolicy to Admins and their Proxies makes

                sense when its value is set to anything other than RejectNew,

                it seems that this value is inappropriate for this policy. In

                fact, because the value applies only at the channel level, it

                seems that it would be better to have it as a separate

                property (rather than an "orthogonal value" of an existing

                property). AND it seems that this property would be better

                grouped with other properties that apply to the channel as a

                whole - the Admin Properties. It would be a boolean valued

                property with the semantics:



                TRUE: when queue resources for the channel are full, do not

                    discard events - rather suspend all pull calls from Proxy

                    Pull Consumers, and raise a <Name of System Exception>

                    exception to all incoming push calls on Proxy Push

                    Consumers.



                FALSE: when queue resources for the channel are full apply the

                    Discard Policy to avoid overruns at each appropriate

                    object where there is a queue.



                With this resolution the Any value for Discard Policy would

                become the default.





Disposition: I personally have no strong feelings about this issue, since

             we (NEC) feel that DiscardPolicy only makes sense on a 

             per-channel basis anyway. But, I'll go along with option c),

             since technically it is the most correct.



VOTE: Voters can vote YES to at most one of 2652a, 2652b, or 2652c. Voting

      YES to one of these means that proposed resolution is the one of choice

      for your company. Voting NO to all 3 is also valid, and means that no

      change should be made with regard to this issue.



NOTE: Only 2652c passed

Summary: The current description of the Reliability quality of service settings
 allows the possibility of modifying quality of service values in 
 a way that would violate validatation rules.
 

Synopsis: The current description of the Reliability QoS settings allows the

          possibility of modifying QoS values in a way that would violate

          validation rules. The issue submitter proposes to add the following

          text to the "Reliability" description on page 54 after paragraph 3:



          "The validity of quality of service reliability level modifications

          depends on the state of Notification Service objects. In general,

          reliability levels may not be modified after a "child" object has

          been created. Such modifications may violate quality of service

          validation rules of the Notification Service."



          "Specifically,



                - modifying the event channel reliability setting through

                  set_qos after ConsumerAdmin or SupplierAdmin objects have

                  been created is invalid, and



                - modifying the ConsumerAdmin or SupplierAdmin reliability

                  settings through set_qos after proxy supplier and proxy

                  consumer objects are created is invalid.



Disposition: I personally do not have any real objection to these proposed

             restrictions on implementations, but I'm not entirely convinced

             they are necessary. We have had extensive e-mail discussions

             about this issue, and I've never fully been convinced that these

             changes are necessary. I would probably vote "abstain" on a vote

             for this issue, and leave it to the consensus to determine whether

             or not to incorporate the proposed changes.



VOTE: YES means to make the changes recommended by the issue author.

      NO means to do nothing.

Summary: The description of the RejectNewEvents does not sufficiently constrain
 its use to the event channel.  
 

Synopsis: The description of the RejectNewEvents setting for DiscardPolicy does

          not sufficiently constrain its use to the event channel. The issue

          submitter proposes the following change to the description of this

          setting in paragraph 8 on page 56:



          "RejectNewEvents - Do not accept new events if the number of queued

                             events in the event channel equals MaxQueueLength

                             and raise the IMPL_LIMIT system exception. Note

                             that this DiscardPolicy setting has meaning only

                             when set on the event channel.



Disposition: I agree with this proposed change.



VOTE: YES means to make the change recommended by the issue author.

      NO means to do nothing.

Summary: The document implies that all factories can assign quality of service
 properties when objects are created. This is not the case.
 

Synopsis: The document implies that all factories can assign QoS properties

          when objects are created. This is not the case. The issue submitter

          proposes the following rewording of paragraph 6 on page 52:



          "The actual set of properties that should be applied by a component

          is derived from merging the set of properties passed to the factory

          with the properties of the component in the higher scope level. In

          cases when a property is present in both places, the property value

          explicitly expressed in the lower level applies."



Disposition: A bit of a nit but I have no problem with this proposed change.



VOTE: YES means to make the change recommended by the issue author.

      NO means to do nothing.

Summary: The CosNotifyChannelAdmin::ProxyConsumer and the
 CosNotifyChannelAdmin::ProxySupplier interfaces define
 the MyType attribute as a ProxyType.
  
 This ProxyType enum is defined as:
 
 enum ProxyType {
 	PUSH_ANY,
 	PULL_ANY,
 	PUSH_STRUCTURED,
 	PULL_STRUCTURED,
 	PUSH_SEQUENCE,
 	PULL_SEQUENCE
 };
 
 The CosTypedNotifyChannelAdmin::TypedProxyPushConsumer and
 the CosTypedNotifyChannelAdmin::TypedProxyPullConsumer
 interfaces inherit the CosNotifyChannelAdmin::ProxyConsumer
 interface.
 Likewise, the CosTypedNotifyChannelAdmin::TypedProxyPushSupplier
 and the CosTypedNotifyChannelAdmin::TypedProxyPullSupplier
 interfaces inherit the CosNotifyChannelAdmin::ProxySupplier
 interface.
 
 The objects inheriting those typed interfaces have no meaningfull
 way to initialize the MyType attribute, therefore I think the 
 PUSH_TYPED and PULL_TYPED values are missing to this enum.
 
 Thua, the resulting ProxyType enum should be defined as:
 
 enum ProxyType {
 	PUSH_ANY,
 	PULL_ANY,
 	PUSH_STRUCTURED,
 	PULL_STRUCTURED,
 	PUSH_SEQUENCE,
 	PULL_SEQUENCE,
 	PUSH_TYPED,
 	PULL_TYPED
 };
 

Synopsis: The ProxyConsumer and ProxySupplier interfaces defined in the

          CosNotifyChannelAdmin module define the MyType attribute, which

          is of type ProxyType. ProxyType is an enumerated type that is

          intended to indicate the specify type of Proxy that an instance

          supporting either the ProxyConsumer or ProxySupplier interfaces

          represents. It's possible values can indicate any of the Proxy

          types defined in the CosNotifyChannelAdmin module. However, the

          Proxy interfaces defined in the CosTypedNotifyChannelAdmin 

          module also inherit either the ProxyConsumer or ProxySupplier

          interfaces, yet the ProxyType data type does not include an

          enumaration that can be used to represent one of the types of

          proxies. To resolve this problem, the following should be added

          as possible values to the ProxyType enum: PUSH_TYPED, PULL_TYPED.



Disposition: I agree with this proposed change.



VOTE: YES means to make the change recommended by the issue author.

      NO means to do nothing.

TimeBase::UtcT where TimeBase::TimeT is needed

Synopsis: The description of the PacingInterval QoS property in section 2.5.5

          states that the data type of the value associated with PacingInterval

          should be TimeBase::UtcT. In the IDL listing in Chapter 3 and also

          Appendix B, the comment under PacingInterval claims the data type

          fo the associated value should be TimeBase::TimeT. The issue author

          proposes to change the text in section 2.5.5 to make it consistent

          with the IDL (i.e., the data type of the associated value should be

          TimeBase::TimeT).



Disposition: I agree with this proposed change.



VOTE: YES means to make the change recommended by the issue author.

      NO means to do nothing.

Synopsis: The "pull" and "try_pull" methods supported by a 

          SequencePullSupplier take an input parameter that indicates the

          maximum number of events the invoker wants to pull. 

          SequencePullSuppliers may also have a MaximumBatchSize QoS

          property associated with them, that also controls the size of the

          batch that will be pulled. The issue author recommends wording be

          added to the spec to state that the input parameter to these methods

          may request some number of events less than or equal to the

          current MaximumBatchSize setting on that proxy, but not more.



Disposition: I agree with this proposed change.

Synopsis: The spec is not clear on the interaction between PacingInterval

          and blocking pull operations. The issue author recommends that 

          specific wording be added to the spec to state that the 

          PacingInterval timer begins at the instance that a sequence-style

          pull supplier receives its first event in a new batch.



Disposition: In our implementation, we start the PacingInterval timer as

             soon as the sequence-style consumer invokes a blocking pull. We

             do not wait until the first event in a new batch is received.

             Personally, I feel our semantic makes a lot more sense. If the

             Consumer configured PacingInterval to a specific value, I think

             it implies that Consumer wants to receive events within that

             time period, if any our available. 



             To more clearly demonstrate the difference between the two 

             semantics here, suppose you have a situation in which a

             SequencePullConsumer has set the PacingInterval of its

             SequenceProxyPullSupplier to 1 minute and has invoked a blocking

             "pull". Now, suppose 10 minutes elapse without any events 

             arriving at that SequenceProxyPullSupplier. If DSTC's semantic

             were applied, the SequenceProxyPullSupplier would still wait an

             additional minute before returning that event, even though the

             Consumer had indicated that it only wanted to wait at most 1 

             minute between receiving event batches. If NEC's semantic were

             applied, the "pull" operation would return immediately after

             reception of the event, because 10 minutes had elapsed since the

             "pull" was invoked, and PacingInterval was only set to 1 minute

             (and thus had long since expired).



VOTE: Because there are two different proposed semantics to resolve this issue,

      I will divide the voting on this issue into 2714a and 2714b. Voting

      YES on issue 2714a means to adopt DSTC's recommended semantic. Voting

      YES on issue 2714b means to adopt NEC's recommended semantic. Voting

      NO on both 2714a and 2714b means to not make any changes in response to

      this issue (since one could argue that this is an implementation detail

      that should not be addressed in the spec). Voting YES on both 2714a and

      2714b is invalid...if you do this I will ask you to recast your vote.



NOTE: Only 2714b passed

The issue author describes the various ways that the Priority

          and Timeout QoS properties can be influenced, and mentions that

          the spec is too vague about the interactions between the various

          mechanisms. Specifically, the issue author enumerates the following

          problems in the spec with respect to this issue:



        1) If the StructuredEvent specifies a Priority/Timeout, and the 

           ProxyConsumer specifies a Priority/Timeout, which one "wins"?



        2) Setting Priority/Timeout on a SupplierAdmin or on the Channel

           is only enabled to be inherited down to a ProxyConsumer, and not

           to have any actual effect. The spec does not state this.



        3) Setting Priority/Timeout on a ConsumerAdmin or ProxySupplier should

           be made illegal (cause UnsupportedQoS with UNSUPPORTED_PROPERTY

           error code to be raised).



        4) If a StructuredEvent does not contain a Priority/Timeout, does

           having this property set on the ProxyConsumer affect the contents

           of the StructuredEvent, or just the way the StructuredEvent is

           treated with respect to these properties.



        5) In the case that a Mapping filter is associated with a

           ProxySupplier, and its constraints all evaluate to FALSE for a

           particular event, does the "default_value" or the value for

           Priority/Timeout associated with the ProxyConsumer take precedence?

Synopsis: The issue author describes the various ways that the Priority

          and Timeout QoS properties can be influenced, and mentions that

          the spec is too vague about the interactions between the various

          mechanisms. Specifically, the issue author enumerates the following

          problems in the spec with respect to this issue:



        1) If the StructuredEvent specifies a Priority/Timeout, and the 

           ProxyConsumer specifies a Priority/Timeout, which one "wins"?



        2) Setting Priority/Timeout on a SupplierAdmin or on the Channel

           is only enabled to be inherited down to a ProxyConsumer, and not

           to have any actual effect. The spec does not state this.



        3) Setting Priority/Timeout on a ConsumerAdmin or ProxySupplier should

           be made illegal (cause UnsupportedQoS with UNSUPPORTED_PROPERTY

           error code to be raised).



        4) If a StructuredEvent does not contain a Priority/Timeout, does

           having this property set on the ProxyConsumer affect the contents

           of the StructuredEvent, or just the way the StructuredEvent is

           treated with respect to these properties.



        5) In the case that a Mapping filter is associated with a

           ProxySupplier, and its constraints all evaluate to FALSE for a

           particular event, does the "default_value" or the value for

           Priority/Timeout associated with the ProxyConsumer take precedence?

           



Disposition: I personally disagree that most of the above claims are really

             issues. Firstly, the order of precedence for the way QoS 

             properties are treated is clearly stated in the spec on page 52

             in section 2.5.3. There, it clearly states that QoS set on a

             per-message level overrides the setting of QoS on any object

             within a channel, and that a MappingFilter is the only thing

             that can override per-message QoS. This takes care of issue 1)

             above. 



             Regarding issue 2), the text in the spec already explains that

             in general, QoS set at a higher level of the object hierarchy

             is used as the default value for the same QoS property at the

             lower levels of the hierarchy, unless specifically set at the

             lower levels. So, of course setting Priority/Timeout on a 

             SupplierAdmin or Channel would be inherited down to a 

             ProxyConsumer. And, I think the model of Notification implies

             that these properties set at the SupplierAdmin or Channel could

             not themselves have any other side-effect. 



             Regarding issue 3), I disagree that setting these properties

             on a ConsumerAdmin or ProxySupplier should be made illegal. If

             a specific implementation cannot derive a useful semantic for

             setting these properties on these objects, they can always raise

             UnsupportedQoS. However I don't think we should preclude the

             possibility that an implementer may find a useful semantic

             for these properties being set on these objects (our does, for

             instance).



             Regarding issue 4), this may be the only point in this issue

             where I agree that the author may have a point. Nowhere does

             it explicitly state that if a StructuredEvent does not contain

             a Priority/Timeout, but one or both of these properties is set

             on the ProxyConsumer that receives it, that the contents of the

             StructuredEvent are not modified, although I believe that's the

             intent. I remember we discussed this issue in our original 

             submitters meeting, and the consensus seemed to be that the 

             channel should never modify the contents of events...in this case

             it would use the QoS properties set at the Proxy level just to

             affect the way the event is treated, and not modify its contents.

             Note that the spec does explicitly state this with regard to

             MappingFilters, but there is no similar text to cover the specific

             case mentioned here.



             Regarding issue 5), the text already specifically states that

             a QoS property's value set as the result of a MappingFilter 

             overrides any other setting of that QoS property, which to me

             means that the default value would take precedence in this case.

             I believe this semantic is already implied by the spec, and that

             no change is necessary.



VOTE: I can't figure out any other way to vote on this issue than to break

      it down to 5 sub-issues. So, the voting will be interpreted as follows:

      

        Issue 2740d: Voting YES means to add text to the spec explicitly 

                     stating that if these properties are set at the Proxy

                     level but not within a StructuredEvent, they are only used

                     to affect the way the event is handled by the channel,

                     and does not cause the event to be modified in anyway.

                     Voting NO means to make no change.

The issue author claims that the spec does not explicitly state 

          when the service starts the "clock" with respect to an event's

          Timeout value. One possibility would be to start the clock as soon

          as the event enters the channel (i.e, at the receiving 

          ProxyConsumer). Another would be to start the clock when the event

          is queued for delivery at the ProxySupplier.

Disposition: The issue author did not state which of the above two possible

             semantics they prefer. Personally, I think the semantic that the

             clock starts ticking as soon as the event is received by the

             ProxyConsumer is the only one that makes sense, so I'll propose

             the voting that way. In reality, though, this is another issue

             in which I feel common sense overrides the need for explicit

             statement.



VOTE: YES means add text stating that the clock starts ticking when the event

      is received by the ProxyConsumer.      

      NO means to do nothing.