[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [energyinterop] FW: Ack Ack
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]