With regards to items 4 and 5 below, I thought the IESG had asked us to =
use the ipp: scheme in the payload urls as well. Did you suggest that IPP =
Clients translate the payload urls from http: to ipp: ?
-Hugo
>>> Ira Mcdonald x10962 <imcdonal@eso.mc.xerox.com> 11/03/98 04:24PM >>>
Hi Paul,
ALMOST the original scheme yes. The important points are:
1) SLPv1 CANNOT operate without a registered concrete scheme=20
(like 'ipp:') for each application service, because they
don't have the syntax for 'abstract services' (lke
like 'printer:') in SLPv1 - it's a technical impossibility
to advertise an IPP Printer in SLPv1 with an 'http:'
published URL - that's the problem I'm worried about.
2) ALL servers (IPP Printer objects) would ONLY advertise
'ipp:' URL, so that they can be found in SLPv1 and
filtered in other directories based on their application
protocol (which is IPP/1.0 as MIME enclosures in
HTTP/1.x transport envelopes).
3) Other than for their initial service advertising, servers
(IPP Printer objects) would NEVER concern themselves
with 'ipp:' scheme URLs.
4) This proposal DOES address the all of the security
requirements of our IETF Applications Area Directors,
WITHOUT incompatible parameters in the 'ipp:' scheme
(whose sole purpose is discovery and support of the
IANA 'well-known' port 631 for IPP default use).
Thanks for your quick reply. Good questions. I hope my
answers help.
Cheers,
- Ira McDonald