Re: issue 6435: v7 of the WS-Eventing state tables

Comments inline . . .

On 1/24/2010 7:02 PM, Doug Davis wrote:
>
> Overall, they look good.  Just a couple of comments:
> - unless the spec specifically talks about one of the boxes in the 
> tables, I don't think it should have anything in that box. For 
> example, all of the "generate fault" boxes should be blank since  a) 
> the spec doesn't say that a fault neesd to be generated, and b) for 
> all of the cases where the spec doesn't say what kind of fault to 
> generate it becomes an implementation choice about what to do.  For 
> example, the "Create Subscription" trigger for a Sink in the "Active" 
> state is out of scope of the spec.

That's what I thought originally but, at the Hursley F2F, I was directed 
to fill in every cell with "something". I agree that saying nothing when 
you have nothing to say is a good course of action.

> - Expiration/Renewing box for Sink: this one I'm unsure of.  It seems 
> to me that until the RenewResponse message is received by the sink 
> then it needs to assume that the timer wasn't reset so going into the 
> End state would be a better choice.

That makes sense, but then you have to make sure that the 
RenewResponse/End cell takes you back to [Active]. That is if you send a 
Renew request, then your local expiration timer goes off, then you get a 
RenewResponse, you have to consider the Subscription to be "Active".

> - SubscribeRequest/Active and SubscribeRequest/End boxes for Source: I 
> think those should be the same as the "Idle" state because regardless 
> of the state of any  Subscription, the way a source deals with a 
> Subscribe Request needs to be the same.

I don't think I fully communicated what I thought it meant for something 
in the "Active" state to get a Subscribe request. Suppose the Event 
Source identified subscriptions using reference parameters. What happens 
if you get a Subscribe request that has those reference parameters and 
their value refers to an already "Active" subscription?

> New version is attached with some other minor edits.

I've attached a new version, with some of your changes accepted. I think 
we should just get these tables into the spec and deal with any issues 
as they come up.

- gp
>
>
>
> thanks
> -Doug
> ______________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> *Gilbert Pilz <gilbert.pilz@oracle.com>*
> Sent by: public-ws-resource-access-request@w3.org
>
> 01/22/2010 04:55 PM
>
> 	
> To
> 	"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
> cc
> 	
> Subject
> 	issue 6435: v7 of the WS-Eventing state tables
>
>
>
> 	
>
>
>
>
>
> As always, the process of working on a related activity (WS-Enum state 
> tables) informs the previous, similar process (WS-Evn state tables). 
> So here is version 7 of the WS-Eventing state tables. The main change 
> is that, similarly to WS-Enum, I pulled out the UnknownSubsription 
> fault into a common action instead of adding pseudo-code to every cell 
> in which it could occur.
>
> As before, please review this and be prepared to discuss at the F2F.
>
> - gp[attachment "Eventing-State-Tables-v7.zip" deleted by Doug 
> Davis/Raleigh/IBM]