Re: [energyinterop] FW: Ack Ack

[rik drummond <rikd@drummondgroup.com>]

I expect you mean at the transfer level not the transport layer. Email and FTP are examples of transfer mechanisms. Tcp is a transfer layer of the OSI stack. 

Very best regards, Rik

Sent from Rik's iPhone

On Mar 27, 2011, at 10:47 AM, "Gerald Gray" <gerald.gray@guiding-principle.com> wrote:

> If we are concerned about reliable delivery this again is something that is
> best handled at the transport layer.
> 
> If we are discussing security we can handle this at the transport layer
> (TLS); cross certificates to handled non-repudiation, etc, and SAML if we
> want to secure the payload.  These are outside the scope of the core message
> payload.
> 
> I think the core question is "Do we need a set of standardized responses"?
> My take is that the answer is "no".  Not when the sending and receiving is
> handled by the transport layer and with message headers.
> 
> If I send a message the context and identification is in the service called
> and the message headers provided.  If I receive a message I have this
> identifying information, act according to my business process, and respond
> based on the service called, identity and message headers provided.
> 
> -----Original Message-----
> From: wtcox@coxsoftwarearchitects.com
> [mailto:wtcox@coxsoftwarearchitects.com] 
> Sent: Saturday, March 26, 2011 8:45 PM
> To: energyinterop@lists.oasis-open.org
> Subject: Re: [energyinterop] FW: Ack Ack
> 
> A bit less  elliptical...
> 
> Toby's #2 is sufficient if and only if no application information need be
> exchanged (which may act as an application-level ACK as well. 
> 
> So #1 was described as application information beyond a simple ACK. So
> perhaps the name should include "respnse" rather than the potentialy
> misleading "ack". 
> 
> #3 is the mechanism for defining and evolving the set of standardized
> responses. 
> 
> Bill 
> 
> 
> Sent via BlackBerry by AT&T
> 
> -----Original Message-----
> From: William Cox <wtcox@CoxSoftwareArchitects.com>
> Date: Sat, 26 Mar 2011 17:23:37 
> To: <energyinterop@lists.oasis-open.org>
> Subject: Re: [energyinterop] FW: Ack Ack
> 
> 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: wtcox@CoxSoftwareArchitects.com 
> <mailto:wtcox@CoxSoftwareArchitects.com>
> 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 <mailto:Toby.Considine@fac.unc.edu>
>> Phone: (919)962-9073
>> 
>> http://www.oasis-open.org
>> 
>> blog: www.NewDaedalus.com
>> 
>> *From:*Girish Ghatikar [mailto:gghatikar@lbl.gov]
>> *Sent:* Saturday, March 26, 2011 4:03 PM
>> *To:* Considine, Toby (Campus Services IT)
>> *Cc:* energyinterop@lists.oasis-open.org
>> *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) 
>> <Toby.Considine@unc.edu <mailto:Toby.Considine@unc.edu>> wrote:
>> 
>> Bringing back to the list.
>> 
>> *From:*Gerald Gray [mailto:gerald.gray@guiding-principle.com 
>> <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:
>> 
>> somemessage.gif
>> 
>> 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 <tel:517.455.4824>| fax: 517.913.6024 
>> <tel:517.913.6024>
>> 
>> *From:*Considine, Toby (Campus Services IT) 
>> [mailto:Toby.Considine@unc.edu <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?
>> 
>> Thanks
>> 
>> tc
>> 
>> 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 <http://unc.edu>
>> 
>> Phone: (919)962-9073 <tel:%28919%29962-9073>
>> 
>> http://www.oasis-open.org
>> 
>> blog: www.NewDaedalus.com <http://www.NewDaedalus.com>
>> 
>> -----Original Message-----
>> From: OASIS Issues Tracker 
>> [mailto:workgroup_mailer@lists.oasis-open.org 
>> <mailto:workgroup_mailer@lists.oasis-open.org>]
>> Sent: Thursday, March 24, 2011 2:57 PM
>> To: energyinterop@lists.oasis-open.org 
>> <mailto: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.atlassi
> an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24965
> #action_24965 
>> 
> <http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348?page=com.atlass
> ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=2496
> 5#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
>> GGhatikar@lbl.gov <mailto: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].
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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 
>