This is the simple scheme that was originally proposed.
My main concern is that I don't see the advantage of doing it (the argument
that it makes the URL more user friendly is invalid.
http://www.zzz.com:631/IPPImp/cgi-bin/ippimp1.cgi?pr=pr1&sec=no and
ipp://www.zzz.com/IPPImp/cgi-bin/ippimp1.cgi?r=pr&sec=no both read
'gobbledeook, blah, blah, jargon' to real human beings). I fit doesnt add
anything then why change what we know already works.
Secondly it can only work if ALL ipp clients do it (otherwise what URL do I
publish as a server IPP or HTTP?)
-----Original Message-----
From: imcdonal@eso.mc.xerox.com [mailto:imcdonal@eso.mc.xerox.com]
Sent: Tuesday, November 03, 1998 12:05 PM
To: imcdonal@eso.mc.xerox.com; ipp@pwg.org
Subject: IPP> MOD - Client-side ONLY 'ipp:' scheme
Hi Paul Moore and IPP folks, Tuesday (3 November 1998)
Paul Moore, please poke holes in the following. Long ago, you stated
that 'ipp:' scheme URL should NEVER be carried in the over-the-wire
IPP/HTTP protocol. You were right!
Shivaun Albight and other printer implementors, this proposal has NO
impact on existing IPP printers OR existing IPP clients.
While editing the SLPv2 'printer:' template for IPP alignment, I found
a serious problem: to advertise IPP printers in SLPv1 (Service Location
Protocol Version 1, RFC 2165, June 1997) a registered scheme of 'ipp:'
is necessary (because abstract services like 'printer:' were only added
in the newer SLPv2, now in IETF Last Call).
Here's a proposal for a minor change to future IPP clients and servers.
This proposal REMOVES ALL redundant security or other parameter(s) in
the 'ipp:' scheme. The simple premise is that a client who wants to use
secure printers MUST be installed in a network with directory services.
1) All IPP Clients (in the future):
a) SHALL accept 'ipp:' scheme printer URL from end-users;
b) SHALL display 'ipp:' scheme printer URL to end-users;
c) SHALL translate 'ipp:' URL to 'http:' for use in HTTP headers;
d) SHALL translate 'ipp:' URL to 'http:' for all IPP attributes in
'application/ipp' MIME bodies (ie, IPP requests or responses).
2) Secure IPP Clients (in the future):
a) SHALL lookup IPP printer URL via the 'ipp:' scheme in SLP, LDAP,
or other directory service, before accessing the IPP printer;
b) SHALL read 'printer-uri-supported' and 'uri-security-supported'
IPP Printer object attributes from the directory service to discover
security info (eg, using the SLPv2 'printer:' template).
3) All IPP Printers (in the future):
a) SHALL put 'printer-uri-supported' and 'uri-security-supported' in
ALL of their directory service registrations (current requirement).
b) SHALL advertise ONLY 'ipp:' scheme URL in directory services
(new requirement).
Let's discuss this at our weekly IPP Telecon tomorrow.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
906-494-2434