Issue 2744: Extended Cleanup of Description of QoS Properties                                                                                                                                                       (pids-rtf2)
Source:  (, )
Nature: 
Severity: 
Summary: The issue author enumerates several points of confusion with 

          regard to the applicability of QoS properties to specific objects

          within a channel. The issues are as follows:



        1) Setting Priority or Timeout on a ConsumerAdmin or ProxySupplier

           is meaningless, and should be disallowed



        2) StartTimeSupport and StopTimeSupported on a ProxyConsumer or

           SupplierAdmin is meaningless, and should be disallowed



        3) OrderPolicy (like DiscardPolicy) on a ProxyConsumer or 

           SupplierAdmin is meaningless, and should be disallowed



        4) MaximumBatchSize and PacingInterval are meaningless for Any

           and Structured Event style Proxies



        The issue author goes onto suggest that Table 2-4 should add

        specific columns for each style of Proxy, so that the applicability

        of QoS properties to specific objects can be designated with finer

        granularity.
Resolution: fixed, see below
Revised Text: For 2744c, texted added to Maximum Batch Size and Pacing Interval

     sections of section 2.5.5. Also added footnote 2 under table 2-4.



     As for 2744d, this issue was actually related to other issues that 

     asked for certain QoS properties that applied to Proxies be constrained

     to particular types of Proxies (i.e., that some apply only to 

     ProxySuppliers and not ProxyConsumers, and vice versa). But, all issues

     of this nature failed to pass, so currently there are no properties

     that are specific to only ProxySuppliers or ProxyConsumers. Thus, I

     really don't see any value in dividing the "Proxy" or "Admin" columns

     into more specific columns, because the subdivided columns would have

     identical entries. 


Actions taken:
June 16, 1999: received issue
November 16, 1999: closed issue
Discussion: 
Issue 1) above overlaps with issue 2740, so will not be 

             considered here. Regarding issue 2), I personally disagree

             with this. I think it's conceivable to set a StartTime or

             StopTime on a ProxyConsumer or a ProxySupplier. When set on

             a ProxyConsumer, it informs that Proxy upon receiving an 

             event with a StartTime or StopTime in its header, it should

             honor that setting. In the case of StartTime, it should not

             queue the event for delivery to ProxySuppliers until StartTime

             has occurred. In the case of StopTime, if the time the event

             is received is later than StopTime, it should simply discard

             the event. In general, I think we should not preclude the

             setting of QoS properties on specific objects unless there is

             clearly no possible semantic that can be associated with them.

             Specific implementations are always free (and still in 

             compliance) to disallow setting of QoS properties on specific

             objects if they choose, but the spec itself should not preclude

             implementors from supporting the setting of a QoS property on 

             specific objects unless that setting very clearly could have

             no meaning. My opinion is that the author of this issue is

             overly concerned that the specification describe the exact

             behavior of their specific information, which I feel is 

             unnecessary in any case (the specification certainly does not

             describe every aspect of the behavior of our implementation!).

             Issue 3) I could go along with, as I cannot think of any

             reasonable meaning that could be associated with OrderPolicy

             on the Consumer side of the channel. I agree that OrderPolicy

             and DiscardPolicy have similar semantics here, and what's 

             already stated in the spec with respect to DiscardPolicy should

             apply to OrderPolicy too. Regarding issue 4), I agree however

             personally feel this is so obvious it doesn't need to be stated.

             Finally, regarding the basic recommendation that table 2-4

             be made more granular (to show applicability of QoS properties

             to specific styles of Proxies), I have no real opposition to 

             doing this, except that it may make it difficult to fit the

             table on the page.



VOTE: Again, I will break down this vote into the following subvotes. Note

      that I consider issue 1) to be covered by issue 2740, so we'll ignore

      that one here.



        Issue 2744c: YES means to state the MaximumBatchSize and

                     PacingInterval do not apply to anything other than

                     Sequence Proxies (and the Channel and Admins that

                     create them). NO means to do nothing.



        Issue 2744d: YES means to break Table 2-4 down into further 

                     columns that show applicability of QoS properties to

                     each specific style of Proxy. NO means to do nothing.


NOTE: 2744c and 2744d passed
End of Annotations:=====