OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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.


On Sat, Mar 26, 2011 at 12:51 PM, Considine, Toby (Campus Services IT) <Toby.Considine@unc.edu> wrote:

Bringing back to the list.


From: Gerald Gray [mailto:gerald.gray@guiding-principle.com]
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:Toby.Considine@unc.edu]
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?








Description: Bill the Cat sez 'ACK!'












"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


blog: www.NewDaedalus.com




-----Original Message-----
From: OASIS Issues Tracker [mailto:workgroup_mailer@lists.oasis-open.org]
Sent: Thursday, March 24, 2011 2:57 PM
To: energyinterop@lists.oasis-open.org
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....



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:



Rish Ghatikar
Lawrence Berkeley National Laboratory
1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
GGhatikar@lbl.gov | +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].

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]