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

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

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

don at lexmark.com don at lexmark.com
Wed Nov 4 09:38:03 EST 1998


Oh, and by the way --- specific support for SLP is NOT a requirement or design
goal as per the DESIGN GOALS document.  I agree it would be nice but if SLP made
design decision that limit it's applicability, well......

Don




paulmo%MICROSOFT.COM at interlock.lexmark.com on 11/03/98 06:34:34 PM

To:   imcdonal%eso.mc.xerox.com at interlock.lexmark.com,
      ipp%pwg.org at 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 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.

Cheers,
- Ira McDonald







More information about the Ipp mailing list