Hi all, It seems that in the current document we have sections on the MDL and MTL. The MTL is deemed to be out of scope, and it is recommended to be "TCP/IP-HTTP-XML (such as SOAP)". Which I would scrap, and just put in SOAP, since NSI does not support any other TCP/IP-HTTP-XML stack. Given that TCP, HTTP and SOAP already provide more than enough delivery assurance, I have to wonder why we actually need that extra conceptual layer in the Message Delivery Layer. It already is basically outsourced to those layers anyway. And for the few cases where upper layer logic is required to make sure that a request is handled correctly, we turn to the State Machine in the form of acknowledgements. I know that the State Machine is currently still being improved. But did we also take the suggestion to make all short exchanges synchronous, and to allow optional acknowledgement for longer asynchronous exchanges? This would make it much simpler to use NSI in cases with limited connectivity (firewalls/clients/NAT etc.) Jeroen. Begin forwarded message:
From: Jeroen van der Ham <vdham@uva.nl> Subject: Re: [Nsi-wg] Query request Date: 2 November 2012 10:20:34 CET To: Jerry Sobieski <jerry@nordu.net> Cc: <nsi-wg@ogf.org>
Hi,
The NSI has chosen to use SOAP and WSDL as its message transport layer. This is a reasonably standard protocol, with support (more or less) in many different languages. For what we aim to do it is pretty good, and it has proven to work pretty well in the past few demos.
You're saying that we should not be projecting lower layer issues into the NSI layer. In my opinion this is exactly what has happened already. And it is also exactly the reason that we are having all these issues.
Reliable message transport layers are readily available off the shelf. TCP makes sure that a packet gets from the source to the destination. On top of that we're using HTTP, which also provides some additional guarantees that the message gets there, including some error codes regarding malformed messages, messages out of order, authentication errors, et cetera. We've used an additional SOAP layer on top, which provides you with even more guarantees.
Can someone please explain to me that in this scenario we really need to have separate confirmation messages? And even if we do, why do these messages have to be exchanged in a completely separate TCP-HTTP-SOAP session?
I understand that we have a state machine, with transition using confirmation messages. But can't we use any of the TCP/HTTP/SOAP status messages to achieve that?
Jeroen.