[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Federation metadata, DNS SRV, and RFC 2782
The federation metadata retrieval mechanism might have some problems, at least from the implementation and deployment perspective: 1. The three retrieval protocols specified, HTTP, WS-Transfer/WS-ResourceTransfer, and HTTPS, are essentially HTTP, with SSL/TLS being a layer 4 technology and with which applications have little choice or use. 2. In the proposed DNS SRV records, the port number definition as such is 80/443/80 (HTTP), which goes against the intention of RFC 2782 - the purpose of which was to provide the discovery of services on a specific host and port (usually not well-known). In essence, the proposed SRV record would only be a pointer to a host name - and not the port - and not the path (which is hard-coded in the spec) or the full URL. The same port for two 'protocols' (HTTP and WS-T/WS-RT) shows the glaring problem in light of the RFC. 3. The hard-coding of the metadata file path (http://server-name/FederationMetadata/spec-version/fed-id/FederationMetadata.xml) along with the redundant 'spec-version' and the 'fed-id' appears to be a problematic scenario for practical development and testing. SUGGESTIONS - 1. Leave an archaic technology such as DNS out of the retrieval mechanism. We are not discovering a service, but essentially retrieving an XML file. The service itself can provide the metadata if it is the IP/STS, or provide a MEPR to the location of the metadata (using the mechanism already built into the schema). 2. Thus the hard-coded retrieval path can be dropped entirely, freeing admins from headaches where application servers and URL mappings are already a nightmare. Especially if the retrieval mechanism is WS-Transfer/WS-ResourceTransfer, it will need to be served using some sort of application server or other server-side logic, and one can only imagine the unnecesary constraints placed on the deployment/administration by such long-winded hard-coded paths. It will most certainly be deployed as a dedicated Web Application. 3. Drop the WS-Transfer/WS-ResourceTransfer retrieval mechanism altogether, or explain its usefulness in the document. With communications essentially being XML-over-HTTP, the response XML can be used to determine whether it is the federation metadata or a WS-Transfer message, with WS-T and WS-RT being a secondary transport/security protocol for the communication of the metadata. -- Ahmed Choudhry
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]