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