Hi Freek; I will note your proposal regarding the base document in the meeting notes. Specifying details regarding a specific implementation of an NMC-capable framework (like perfSONAR or something completely different) does not seem correct to me. I still believe that we do not want to box ourselves in by saying "use SOAP over HTTP because that's what the first generation used". The strength of this work should lie in the specification and meaning of the XML - if it travels over pigeons or wires should not be a primary concern. The documents that I think you and Michael speak of belong to the projects that implement these protocols into specific services. We commonly refer to 'perfSONAR capable' services as services that speak perfSONAR protocols. In this case we should be saying, 'perfSONAR is really NMC that travels on SOAP over HTTP'. I would argue that these specifications should be undertaken by these projects, not by NMC. Thanks; -jason
Michael Bischoff wrote:
After discussing some of this off list with Jason it seems we are leaning towards how it was done SAML spec the base is completely transport agnostic and perhaps specify later how to bind these (http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf)
I think it is reasonable if the base document is transport agnostic, but I would be very much in favour if it is documented somewhere: after all, if I read NM charter, it is chartered with defining a schema, while NMC is chartered with defining a protocol. So, I would say: define exactly what is going over the wire. That includes specifying the underlying transport protocol, as long that is a concern for the end-hosts (so it must be defined up to the transport layer (in this case: define that we use SOAP + HTTP + TCP and that the port number should be looked up in the lookup service).
The only drawback of this approach is the plethora of documents we're creating, but otherwise it seems fine with me.
If we agree, I will rework the SHOULD and MUSTs in the base document according to this agreement, and note that the transport protocol is defined elsewhere.