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
--=====================_97715597==_.ALT
Content-Type: text/html; charset="us-ascii"
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
--=====================_97715597==_.ALT--