attachment-0001

<html> I talked to Ira about the differences of our ideas and I think that we have a resolution.  But I hope others from ipp and svrloc will reply to these ideas. Before our discussions, I was assuming that an SLP DA would contain a separate entry for each URI associated with a printer. This seems to be the natural way to use SLP where a printer URI is associated with a collection of attributes. Ira was assuming that an SLP DA would contain exactly one entry per printer. It would be arbitrarily associated with one of the printer's URI and the collection of attributes would contain information for all of the printer's URI. Ira preferred having one entry per printer because it reduces the amount of information to register and avoids the propagation problem where a DA, during times of re-registration has a mixture of new and old registrations for a printer. This problem arises with printers because they typically support many protocol stacks, and thus potentially many URI's. As we talked about it, I realized that Ira's solution is closer to the way I understand Jini to work. Each name service entry in Jini is just a collection of objects without any special name associated with it. We can make SLP look like Jini if we view the SLP name as an object handle, and the SLP entry as the collection of objects referenced by this object handle. When we examined the issue of associating each URI with security information, I realized that we could use the "service: URL" syntax for security information. A "service: URL" can have attributes that follow the URL path and that these attributes can be defined in the printer template document. It isn't clear to us if the attributes names in the "service: URL" should also appear as regular attributes in the template. Do any svrloc experts know? So we think that the solution is that a printer registers a single entry and that one of the attributes is "printer-uri-supported", which contains a collection of "service: URLs", one for each way that the printer can be contacted. Each of those URL's must have all information needed for a client to be able to communicate with the printer. The name of this entry in the DA is arbitrary, but the first URL in the printer-uris-supported is reasonable. This solution suggests that IPP be changed to drop the "uri-security-supported' attribute from IPP v 1.0 and change 'printer-uri-supported" to contain "service: URL"s. I expect that the support for security at this time is such that this is an easy 1.0 bug fix. Bob Herriot </html>