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

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

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

Hugo Parra HPARRA at novell.com
Tue Nov 3 19:56:00 EST 1998


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 at 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 
    (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