Don
paulmo%MICROSOFT.COM@interlock.lexmark.com on 11/03/98 06:34:34 PM
To: imcdonal%eso.mc.xerox.com@interlock.lexmark.com,
ipp%pwg.org@interlock.lexmark.com
cc: (bcc: Don Wright/Lex/Lexmark)
Subject: RE: IPP> MOD - Client-side ONLY 'ipp:' scheme
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