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

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

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

Paul Moore paulmo at microsoft.com
Tue Nov 3 18:34:34 EST 1998

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 at eso.mc.xerox.com [mailto:imcdonal at eso.mc.xerox.com]
Sent: Tuesday, November 03, 1998 3:25 PM
To: imcdonal at eso.mc.xerox.com; ipp at 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.

- Ira McDonald

More information about the Ipp mailing list