Federation metadata, DNS SRV, and RFC 2782

["Ahmed Choudhry" <ahmed@dyanet.com>]

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