There are several levels here.
First, there is a need for application level acknowledgment strings
with specific meanings. That was the reason for the strings.
Second, there is the "reliably delivered" aspect. One needs to
compose the relevant and required security and reliability for each
{VTN, VEN} set.
Third, the "reliable delivery" protocols are NOT a guarantee of
ACTUAL Delivery. (offline discussion any time; they increase the
likelihood that you can assume delivery once sent, but are not a
panacea).
Toby's #2 addresses my first item.
bill
--
William Cox
Email:
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax
On 3/26/11 4:29 PM, Considine, Toby (Campus Services IT) wrote:
So the question I am wrestling with, in the
specific context of the recently published schemas for EI,
is what to do with all the ACK strings that are in messages.
(1) They should be in an overall transaction
framework, and are outside of scope
(2) They have specific meaning and purpose, and give
hints to the overall transaction framework on how to track
messages
(3) They have specific enumerations for each
interaction type, and those enumerations need to be
understood by the consuming programs
Etc.
tc
"It is the theory that decides what can be
observed."
- Albert Einstein
Toby Considine
Chair, OASIS oBIX Technical
Committee
U.S. National Inst. of Standards
and Tech. Smart Grid Architecture Committee
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
Email: Toby.Considine@
unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com
From: Girish Ghatikar
[mailto:]
Sent: Saturday, March 26, 2011 4:03 PM
To: Considine, Toby (Campus Services IT)
Cc:
Subject: Re: [energyinterop] FW: Ack Ack
It was my understanding that the ACK is
part of the message transport requirements. This visits TCP or
UDP requirements (reliable vs. not reliable transport). If the
ACK is used in this context, we're suggesting specific
implementations (of course, version of UDP, reliable UDP, acts
mostly like TCP).
In OpenADR, we had a message
"confirmation" on top of the implementation-specific ACK.
The confirmation goes beyond sending the ID to confirm the
receipt of message -- it also includes returning some
specific information as part of the message.
Thanks,
-Rish
On Sat, Mar 26, 2011 at 12:51 PM,
Considine, Toby (Campus Services IT) <>
wrote:
Bringing back to the list.
From: Gerald Gray [mailto:]
Sent: Friday, March 25, 2011 4:30 PM
To: Considine, Toby (Campus Services IT)
Subject: RE: Ack Ack
Hi Toby, let’s see if I can
explain further. I didn’t know how much detail I
should go into the jira; didn’t want to write a book
if it was something we were going to discuss on the
call.
As noted in the jira we have
various and sundry Ack types (love the image below
BTW – big Bill The Cat fan). For my part I am not
certain of the use of the Ack in the different
payloads, hence my lack of clarity in suggesting a
fix.
It looks like this is something
we want to set once we return the call in the
service operation. Is this your understanding? For
example, are we trying to do the following:
That is, after we have sent a
message to System B, are we trying to let System A
know that we have received it?
If that is the purpose I think we
can simply remove the various Acks from the message
payloads. This is because normally an “ack” of this
sort is an implementation thing. For example, if
someone was going to implement a web service there
would be a message header associated with the
service that is going to contain bits of information
important to both System A and System B. There
would probably be a unique ID for the message itself
for example. The “ack” aka return (the dashed line
in the diagram) would reference this ID (or other
identifying information) that tells System A “yep we
got it”. For this reason we don’t need to include
an Ack in the message payload; as I said, it’s an
“implementation thing”.
If Ack is not used for this
purpose, i.e. some sort of status used by System B,
then we can delve into how we can abstract this out.
Does that makes sense?
Cheers -
Gerald R. Gray, PhD
Guiding Principle Consulting
PO Box 381
Laingsburg, MI 48848
cell: 517.455.4824| fax: 517.913.6024
From: Considine, Toby
(Campus Services IT) [mailto:]
Sent: Friday, March 25, 2011 2:26 PM
To: Gerald Gray
Subject: Ack Ack
Can you give me more specific detail or say if I am
on the right track?
Thanks
tc
"It is the theory that decides what can be
observed." - Albert Einstein
Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid
Architecture Committee
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
blog: www.NewDaedalus.com
-----Original Message-----
From: OASIS Issues Tracker [mailto:]
Sent: Thursday, March 24, 2011 2:57 PM
To:
Subject: [energyinterop] [OASIS Issue Tracker]
Commented: (ENERGYINTEROP-348) Use of "Ack" as a
string
[ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24965#action_24965
]
Toby Considine commented on ENERGYINTEROP-348:
----------------------------------------------
My favorite issue that I hhad not yet entered.
Do we need a Bool and the 61698, or one, or....
dateTime
reason - not enumerated, do we need to?
remark free form
status, recommend app specific enum...
Note that for types of documents, the status is
regarding the subject matter (e.g., TroubleTicket,
SwitchingSchedule, Work, WorkTask, Specification,
TypeAsset, AssetModel, etc.) of this particular type
of document. It is not the status of the document,
which is found in 'docStatus'.
> Use of "Ack" as a string
> ------------------------
>
> Key: ENERGYINTEROP-348
> URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348
> Project: OASIS Energy Interoperation
TC
> Issue Type: Bug
> Components: model, schema
> Affects Versions: wd22
> Reporter: Gerald Gray
> Assignee: William Cox
>
> Throughout the model there are various uses of
"ack" type attributes which have been set to the data
type of string. An ack type action is probably best
reflected as a Boolean.
> However, the repeated uses of "ack" attributes
throughout the model suggest this attribute may be
abstracted out. In addition if more information about
an acknowledgement is needed there may be an
opportunity to leverage the Status class from CIM.
> IEC61968.Common.Status (compounded class) This
class contains
> dateTime, reason, remark, value that may be
leveraged for this purpose.
--
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave
the OASIS TC that generates this mail. Follow this
link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
| +1 510.486.6768 | +1 510.486.4089 [fax]
This email is intended for the addressee only and may
contain confidential information and should not be copied
without permission. If you are not the intended recipient,
please contact the sender as soon as possible and delete the
email from computer[s].
