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)...