SLP is broken. It does not recognize that a printer is a printer is a
printer regardless of what the transport protocol is. A client has to look
for IPP printers, then LPR printers, then IPDS printers then TFTP printers,
then XYZ printers. The protocol used should be an attribute of the service
not the service discriminator. If a client only support xyz protocol then it
should look for 'printers' with 'protocol=xyz' not for 'xyzprinters'.
secondly you are now off into discussing security again. This is confusing
to me because you mentioned in the original mail that you wanted to stop
discussing security.
I have no objection to doing something that gets us to some good place in
the future. I just want to see a complete proposal that stands still for > 1
week, that would actually work and that solves real problems now or in the
future.
-----Original Message-----
From: imcdonal@eso.mc.xerox.com [mailto:imcdonal@eso.mc.xerox.com]
Sent: Tuesday, November 03, 1998 6:28 PM
To: imcdonal@eso.mc.xerox.com; ipp@pwg.org; Paul Moore
Subject: RE: IPP> MOD - Client-side ONLY 'ipp:' scheme
Hi Paul,
This isn't just a way forward for service advertising (although
that's a pretty important requirement for real printer offerings).
This is a fundamental way forward on security. By publishing
'ipp:' URL in directories, IPP Printers would be advertising
their explicit security capabilities in those directory
objects, NOT in parameters embedded in 'http:' URL (impossible,
we can't extend them) or 'ipp:' (awful, we can't freely
translate them to and from 'http:' URL).
Since NONE of the shipping clients or printers can possibly
be doing Internet standards-based advertising of their printers
because there ISN'T any LDAP
'printer:' schema published and the SLP 'printer:' template
is still under development, the addition of standards-based
security capabilities discovering is a FUTURE feature.
The point is where we migrate to, not where we are with the
implementations that had so much success interworking last
month in Redmond.
A very small change in the protocol (strictly client-side
massaging of 'ipp:' URL to/from 'http:' URL for all HTTP
and IPP protocol elements) is a very small price for getting
IPP/1.0 back on stable footing on the Internet 'standards
track'. And it works with all existing IPP Printer
implementations (well, ones which are otherwise IPP/1.0
June 1998 drafts compliant).
Cheers,
- Ira McDonald
High North Inc
906-494-2434
PS - SLPv1 isn't broken - it made the reasonable assumption
that all applications of interest for advertising have
(or will register) standard URL schemes. IPP/1.0 is the
broken one - it's trying to get away without a scheme
and is making no headway at all in the IESG on this
basis.
PPS - Anyway, we all try to support HTTP/1.0 too in our
implementations, even though we know HTTP/1.1 is better.
And we'll go on supporting SSL3 in secure implementations
for YEARS after TLS becomes final (if ever)...