OASIS Energy Interoperation TC

  • 1.  FW: Ack Ack

    Posted 03-26-2011 19:52
    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?   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      


  • 2.  Re: [energyinterop] FW: Ack Ack

    Posted 03-26-2011 20:04
    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 > 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?   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


  • 3.  RE: [energyinterop] FW: Ack Ack

    Posted 03-26-2011 20:30
    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: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 > 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?   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


  • 4.  Re: [energyinterop] FW: Ack Ack

    Posted 03-26-2011 21:24
    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 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: 49388A5276025649AC24AF97ADB9DA627122D283B8@facmailmb3.facilities.unc.edu type= cite > 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: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 > 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?   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


  • 5.  Re: [energyinterop] FW: Ack Ack

    Posted 03-27-2011 00:45
    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


  • 6.  RE: [energyinterop] FW: Ack Ack

    Posted 03-27-2011 15:48
    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


  • 7.  Re: [energyinterop] FW: Ack Ack

    Posted 03-28-2011 12:41
    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


  • 8.  RE: [energyinterop] FW: Ack Ack

    Posted 03-28-2011 16:32
    Hi Rik, more importantly, would you concur that message acknowledgement is something that has been solved outside of the message payload and is part of implementation?
    Original Message


  • 9.  Re: [energyinterop] FW: Ack Ack

    Posted 03-29-2011 13:34
    I would have to look at the spec in detail. ACKs are protocol level specific.... Each level has their own to verify the packet was received without errors. So using the OSI 7 layers, each layer would normally have it's own ACK structure. One has to be careful using ACKs from lower levels in upper layers because ACKs may have different functional meanings. That is not the answer, but it is all I have time for now. ACKs may not, usually do not give nonrepudiation functionality... That requires digital signatures.. Rik Sent from Rik's IPAD Rik Drummond CEO, Drummond Group Inc On Mar 28, 2011, at 11:31 AM, "Gerald Gray" <gerald.gray@guiding-principle.com> wrote: > Hi Rik, more importantly, would you concur that message acknowledgement is > something that has been solved outside of the message payload and is part of > implementation? > >
    Original Message