Chuck Rice and I have been working on a proposal for service directories for PPDT. We have reached the following conclusions:
Service discovery has two distinct uses:
* O/S discovery (i.e. plug 'n play);
* Application discovery.
The major difference between the two is that plug 'n play tends to be a boot-time process used to install and load drivers, while application discovery tends to be a run-time process used to configure applications and select services.
Plug 'n play itself has two distinct applications: simple and complex devices. A camera is a good example of a simple device. It uses service discovery to verify that the one service that it needs is available. A PC is a good example of a complex device. The PC's O/S could use service discovery to enumerate all available services and load drivers for them. I use the word "could" quite intentionally. Currently, O/S's tend to enumerate at the device-level. For 1394, we want the 0/S's to enumerate at the functional-instance-level. I think that is the right solution and don't see value in service-level plug and play.
Plug 'n play enumeration needs to happen quickly, as it tends to delay booting. Having the service directory available in config ROM is the quickest solution, as a PPDT command would first require time to execute a login.
Application discovery is a more complex topic. A simple application can just try to connect to the service(s) that it requires. If they are not there, the connect will just fail. (Note: The Winsock2 entry "connect" can return a specific error value if the service does not exist.)
A more complex application may want to discover services first and then connect to a specific combination of services based on which services were available. I use the word "may" because I am not currently aware of any applications that do this.
If service discovery is to be provided to applications, it makes sense to implement it via transport commands for a couple of reasons. If the transport is ported to other physical links, the service discovery mechanism comes along with it. This is a valuable feature of 1284.4 for example. I don't think this applies to PPDT, since it is quite 1394-specific and will probably never be implemented on other physical links.
Another good reason to implement at the transport-level is basic layering. The transports have all of the service name information available to them and can communicate directly to the applications. If the service name information is exchanged at another level, say in config ROM, then the transport provider (e.g. Winsock2 implementation) will have to have access to the config ROM itself. This is a concern for PPDT and 1394 as there are several layers between them (e.g. SBP-2).
One other note about application discovery. Providing a simple list of service names to the application may not be sufficient. It may need to have access to attributes of the services or have the services grouped in some way. Service discovery protocols that provide these capabilities do exist. The best way to provide application discovery when it is needed in the future might be to implement one of these protocols on top of PPDT.
To summarize the preceding paragraphs, service discovery can be split into two uses: plug 'n play and application discovery. Plug 'n play is best implemented at a low level, e.g. in config ROM. Application discovery is best implemented at the transport level for portability and layering, BUT, it can be implemented at a low level if the transport provider has access, AND most applications (all that I am aware of now) can simply try connecting to the desired services.
Our conclusion is that service discovery is a valuable feature, but only for simple device plug 'n play. Service discovery could possibly be useful for future complex device plug 'n play and application discovery, but that could be implemented using a separate, more-functional, service discovery standard.
We propose that PPDT implement service discovery in the feature directory of config ROM, as defined in clause 8.3 of PPDT_r0X. The Service_ID key should remain optional, as it is only needed by devices that wish to advertise services. Device class profiles (e.g. the future PWG printing profile) might chose to mandate the advertisement of certain services (e.g. a simple image printing protocol). The SERVICE DIRECTORY control and PPDT SERVICES service should be removed from the specification, as they will have little to no use and replicate functionality available through the Service_ID key and other, more functional, service discovery protocols.
Brian (and Chuck)
Brian Batchelder - mailto:batchelder@ieee.org
IEEE 1212r Chair, IEEE 1284.4 Editor, 1394 Printer Working Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~