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

Paul Moore (paulmo@microsoft.com)
Tue, 3 Nov 1998 15:34:34 -0800

So the only reason to do it is because SLPv1 is broken. Its function concept
is bound to protocols.

You do agree that ALL clients have to change before anything ships - like
right now!

-----Original Message-----
From: imcdonal@eso.mc.xerox.com [mailto:imcdonal@eso.mc.xerox.com]
Sent: Tuesday, November 03, 1998 3:25 PM
To: imcdonal@eso.mc.xerox.com; ipp@pwg.org; Paul Moore
Subject: RE: IPP> MOD - Client-side ONLY 'ipp:' scheme

Hi Paul,

ALMOST the original scheme yes. The important points are:

1) SLPv1 CANNOT operate without a registered concrete scheme
(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