[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (ENERGYINTEROP-481) 1039 eiRequestEvent - consumer/provider is either; which event is requested, how to handle event cancel
[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Toby Considine updated ENERGYINTEROP-481:
-----------------------------------------
Resolution:
Add EiRequestEvent/EiReplyEvent to Figure 81- line 1127 wd28.
Add text as in Cox comment on the expected response time range.
A new section on special semantics of Event Requests has been added to the section on the Evetn Service
was:
Add EiRequestEvent/EiReplyEvent to Figure 81- line 1127 wd28.
Add text as in Cox comment on the expected response time range.
Other jira issues
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-635
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-634
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-625
http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-626
have addressed the issues of defining active and pending, or filtering events, of limiting events to an interval of concern. Filters and requests for completed and cancelled events are legal, but there is no expectation or requirement to return them as smaller devices are unlikely to maintain extensive histories.
A new section on special semantics of Event Requests has been added to the section on the Evetn Service
> 1039 eiRequestEvent - consumer/provider is either; which event is requested, how to handle event cancel
> --------------------------------------------------------------------------------------------------------
>
> Key: ENERGYINTEROP-481
> URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-481
> Project: OASIS Energy Interoperation TC
> Issue Type: Improvement
> Components: spec
> Affects Versions: wd25
> Environment: Bartell
> Reporter: Bruce Bartell
> Assignee: Gerald Gray
> Priority: Minor
> Fix For: wd29
>
>
> Table 8-1 says consumer/provider for eiRequestEvent is either. Does this mean that either the VEN or VTN can initiate the request? This case is not covered in the sequence diagram provided in Figure 8-1. I think this is covered in Figure 1-2 w/o the either scenario.
> Which event is being requested? Is it "assumed" to be current or next if there is no current? If this is how it is done, what happens if an event is cancelled? When the VEN requests another event message and a new event shows up it is assumed the event if over? I thought 9.3.1 Interaction Patterns for the EiStatus Service would clear this up, but there is event id there either.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]