IPP Mail Archive: RE: IPP> MOD - Client-side ONLY 'ipp:' scheme

IPP Mail Archive: RE: IPP> MOD - Client-side ONLY 'ipp:' scheme

RE: IPP> MOD - Client-side ONLY 'ipp:' scheme

Hugo Parra (HPARRA@novell.com)
Tue, 03 Nov 1998 17:56:00 -0700


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: ?


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

- Ira McDonald