attachment-0001

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