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

Jira Issues

Issue 1423: Add destroy operations Jira Issue NOT11-2
Issue 1424: Fix existing bug in CosTypedNotifyChannelAdmin IDL Jira Issue NOT11-3
Issue 1425: Define new Service ID Jira Issue NOT11-4
Issue 1426: Make section 2.10 consistent with current CORBA 2.1 Jira Issue NOT11-5
Issue 1427: Clean up description of QoS properties Jira Issue NOT11-6
Issue 1499: Error in Event Type Repos IDL in Notification Jira Issue NOT11-7
Issue 1524: <CompEsc> lexical token issue Jira Issue NOT11-8
Issue 1580: We need default value for DiscardPolicy Jira Issue NOT11-9
Issue 1584: Reference to MaxQueueLength--QoS issue for Notification Jira Issue NOT11-10
Issue 1618: subscription_change issue Jira Issue NOT11-11
Issue 1638: Filter grammar problem Jira Issue NOT11-12
Issue 1660: No way to "quench" to event style supplier Jira Issue NOT11-13
Issue 1680: Use of lexical components Jira Issue NOT11-14
Issue 1681: Syntactic category <Factor> includes <Ident> and \<Ident>...Why? Jira Issue NOT11-15
Issue 1682: Section 2.4.6 : positional notation wrt to unions Jira Issue NOT11-16
Issue 1684: Constraint Language issue Jira Issue NOT11-17
Issue 1706: comment_*() operations needed in CosNotifyComm Interface Jira Issue NOT11-18
Issue 1773: No way to "quench" typed event style clients... Jira Issue NOT11-19
Issue 1774: ProxyConsumer and ProxySupplier need readonly attributes to identify type. Jira Issue NOT11-20
Issue 1791: Move name up to PropertyErorr and create a NamedPropertyRange struct Jira Issue NOT11-21
Issue 1792: Remove the use of CosTrading property types Jira Issue NOT11-22
Issue 1793: Dependance on CosTrading Jira Issue NOT11-23
Issue 2008: Removal of explicit Transactional interfaces Jira Issue NOT11-24
Issue 2113: Editorial issue Jira Issue NOT11-25
Issue 2114: Cardinalities for "imports" and "inherits" wrong Jira Issue NOT11-26
Issue 2120: Suspension of connections Jira Issue NOT11-27
Issue 2121: Another issue related to suspend/resume connection Jira Issue NOT11-28
Issue 2153: CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper Jira Issue NOT13-1
Issue 2157: .Clarification of pull_structured_events definition Jira Issue NOT11-29
Issue 2203: Notification Constraint language problem Jira Issue NOT12-1
Issue 2211: The term name-value pair is not well defined Jira Issue NOT12-2
Issue 2212: Footnote on page 34 Jira Issue NOT12-3
Issue 2213: The section 2.4.5 Jira Issue NOT12-4
Issue 2216: Issue with the algorithm for evaluating $<variable> expressions Jira Issue NOT12-5
Issue 2217: Not all references to event types have been updated Jira Issue NOT12-6
Issue 2219: Text on p. 54 describing applicability of EvenReliability QoS out of date Jira Issue NOT12-7
Issue 2220: Explicit statement missing in contraint grammar Jira Issue NOT12-8
Issue 2229: Inconsistency on p 54 Jira Issue NOT12-9
Issue 2297: Unnecessary restriction defined on Mapping Filters Jira Issue NOT12-10
Issue 2433: CosNotification -- MaxEventsPerConsumer = 0 for infinity? Jira Issue NOT12-11
Issue 2434: Default values for PacingInterval and MaximumBatchSize QoS properties? Jira Issue NOT12-12
Issue 2448: EventType IDL typos Jira Issue NOT12-13
Issue 2460: EventTypeRepository class issue Jira Issue NOT13-2
Issue 2501: Premature in eliminating Txn interfaces? Jira Issue NOT13-3
Issue 2512: suspend_connection/resume_connection messages - issue Jira Issue NOT13-4
Issue 2554: Filter evaluation in pull mode Jira Issue NOT12-14
Issue 2555: Semantics of Disconnected exception Jira Issue NOT12-15
Issue 2652: Modify the DiscardPolicy text, paragraph 1 page 56 Jira Issue NOT12-16
Issue 2653: To add to "Reliablity" text, Page 54 after paragraph 3. Jira Issue NOT12-17
Issue 2654: Modify RejectNewEvents description, paragraph 8 page 56 Jira Issue NOT12-18
Issue 2655: Modify paragraph 6, page 52 Jira Issue NOT12-19
Issue 2662: CosNotifyChannelAdmin module: typed proxies not defined in ProxyType enum Jira Issue NOT12-20
Issue 2712: TimeBase::UtcT where TimeBase::TimeT is needed Jira Issue NOT12-21
Issue 2713: Pull Methods on Sequence Suppliers Jira Issue NOT12-22
Issue 2714: Problem with Sequence Pull Model Jira Issue NOT12-23
Issue 2740: Clarify Handling of Priority and Timeout Jira Issue NOT12-24
Issue 2743: Semantics of Timeout Value Jira Issue NOT12-25
Issue 3114: Semantics of Event Service disconnect_push_consumer/supplier() Jira Issue NOT13-11
Issue 3156: Typed event service and disconnect Jira Issue NOT13-12
Issue 3175: Notification service: admin MyChannel attribute Jira Issue NOT13-5
Issue 3517: Section 3.4.17. Page:136 Jira Issue NOT13-6
Issue 3518: Issue with pushing events Jira Issue NOT13-7
Issue 3519: The interface on EventChanel does not have the ability to get the ChannelId Jira Issue NOT13-8
Issue 3520: The interface on EventChanel does not have the ability to get the ChannelId Jira Issue NOT11-30
Issue 3521: The Supplier Proxy & Consumer Proxy interfaces don't get ID's Jira Issue NOT13-9
Issue 6343: Notification Service IDL issues Jira Issue NOT13-10
Issue 9079: MaxEventsPerConsumer Jira Issue NOT11-1

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: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier   operation, when asked for a proxy for a ClientType of ANY_EVENT,   returns a proxy that is unuasable by event service clients.      The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface   returned inherits only from CosEventChannelAdmin::XSupplier, and then   redefines the connect operation that was available in CosEventChannelAdmin::   ProxyXSupplier as connect_any_x_supplier. The interface can never be   narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is   unusable by the Event Service style client.       

: 

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: In Appendix A it is stated that "the EventTypeRepository class only has   one instance in any given implementation of the Repository". At the same   time, there is a package interface and a package factory that implies   that it"s possible to create multiple repositories (unless the   NotificationTypesPackage interface is expected to always returns the   same objects, no matter how many packages one have created).    

Summary: I feel there is a flaw in the model described in the current Notification    Service spec for supporting Transactional Notification.    

Summary:     The  suspend_connection/resume_connection messages do not describe what should happen  to messages that are queued up.  Are new messages rejected for the duration  between the disconect and resume?  Are messages that were queued up  flushed?  How does the Persistent Event Reliablity QoS effect the way both  are handled? size=2>  Along  the same lines, what happens to events when a consumer disconnects?  I  assume events in this case would be lost. 

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.    

The question concerns the disconnect_push_consumer() family of operations  (push and pull, consumer and supplier) on both the Event Svc side (proxy  suppliers and consumers) and application side (suppliers and consumers).    1) Is a proxy's disconnect_..._...() meant to be called by (any or all of)     - the corresponding application supplier/consumer?     - some other part of the application?     - any portion of the Event Svc implementation?  If "yes" in this case,       is the connected application object also supposed to be invoked, to       notify it of the proxy's shutdown?    2) Is an application consumer/supplier's disconnect_..._...() meant to be     called by     - some other part of the application?  If "yes" in this case, is the       application consumer/supplier then expected to invoke disconnect_()       on the corresponding proxy object?     - any portion of the Event Svc implementation?  If "yes", under what       circumstances?    The specific issue at hand presumes the application object's disconnect_()  operation is to be invoked by the Event Svc.  The question is when -- one  opinion is that a call to the proxy's disconnect_() results in the invoca-  tion of disconnect_() on the proxy's application object.  The opposing o-  pinion is that the application object's disconnect_() is invoked only when  the application object is being disconnected by some means other than a  call to the proxy's disconnect_() (for example, if the event channel's  destroy() is called while application objects are still connected).  

When a channel is destroyed, all its proxies invoke the disconnect callback (if a callback was registered). In addition, calling a disconnect operation on a proxy causes the proxy to make the appropriate disconnect callback. Proxy implementations are responsible for avoiding infinite recursion. See http://cgi.omg.org/pub/notification-rtf/2_modules_draft1.pdf for a version of the original specification that includes the edits for this issue marked with change bars.

For the untyped event service, a Disconnected exception is raised  if push() or pull() are called by the appropriate connect operation wasn't  called previously.    What should happen if I use a typed event service?  

Typed consumers and suppliers cannot be forced to offer a Disconnected exception, so a system exception must be used.

The notification service administration objects support an attribute  called MyChannel that returns the event channel that first created the  administration object. The value type of this attribute is EventChannel.  For typed administration objects, the typed channel can not be returned  because a TypedEventChannel is not compatible with an EventChannel. One  solution is to change the value type of this attribute to a generic  Object, which can be narrowed to the correct type.  

I see the following features lacking in CosNotification spec.  What is the process on having this raised as   an issue, and if all agree add it to the spec in the later revisions.  Any info is appreciated.    1. Section 3.4.17.  Page:136. The EventChannel interface in CosNotification, does not allow to retrieve  its ChannelId.  This is unlike the interface on the admins which allow to get the adminids?  It would be   very handy to retrieve the channel id given event channel.  I also do not see a way to retrieve   proxyId's given a consumer proxy or supplier proxy.  

2. Publishers are allowed to push events for the types they have not offered using offer_change().   This can allow publishers to never advertise the event types they are offerring.  For Example, as   a consumer it can not tell what are the event types that will be offered on the channel.     Can we require publishers to always call offer_change() on the new event types before pushing them to   the event channel?  If this behavior breaks existing functionality, then how about having push_xxx()  check to see if the event type is offered, if not add it to the aggregate list?  

1. The interface on EventChanel does not have the ability to get the ChannelId?  This   is quite contrary to the ability on the admin interfaces to retrieve the adminId's.   Given a proxy to EventChannels's it will be very handy to retrieve the channelId's.

1. The interface on EventChanel does not have the ability to get the ChannelId?  This   is quite contrary to the ability on the admin interfaces to retrieve the adminId's.   Given a proxy to EventChannels's it will be very handy to retrieve the channelId's.

The interface on EventChanel does not have the ability to get the ChannelId?  This   is quite contrary to the ability on the admin interfaces to retrieve the adminId's.   Given a proxy to EventChannels's it will be very handy to retrieve the channelId's. The Supplier Proxy & Consumer Proxy interfaces also do not have the ability to get   the ID's.

just came across Notification Service IDL where  you are mentioned as contact person:      When I  "grep"  on  all  IDL files I notice that   orb.idl is not included.       I notice further that file        CosNotifyFilter.idl      in line 105 makes use of TypeCode:        readonly attribute CORBA::TypeCode value_type;       However section 3.19 "CORBA Module" of current   CORBA standard 3.0.2 reads as:      >> Names defined by the CORBA specification are in a module named CORBA. In an  >> OMG IDL specification, however, OMG IDL keywords such as Object must not be  >> preceded by a "CORBA::" prefix. Other interface names such as TypeCode are not  >> OMG IDL keywords, so they must be referred to by their fully scoped names (e.g.,  >> CORBA::TypeCode) within an OMG IDL specification.  >> For example in:  >> #include <orb.idl>  >> module M {  >> typedef CORBA::Object myObjRef; // Error: keyword Object scoped  >> typedef TypeCode myTypeCode; // Error: TypeCode undefined  >> typedef CORBA::TypeCode TypeCode;// OK  >> };  >> The file orb.idl contains the IDL definitions for the CORBA module. Except for  >> CORBA::TypeCode, the file orb.idl must be included in IDL files that use names  >> defined in the CORBA module. IDL files that use CORBA::TypeCode may obtain its  >> definition by including either the file orb.idl or the file TypeCode.idl.      In my humble opinion, "your" Notification IDL is  not correct.      Perhaps  you  have  some time left to comment on  this?  

The type of MaxEventsPerConsumer should be an unsigned long, why should this be long, so far as I can't tell there is no need for a negative number