I would not give up on this quite yet, there are still only a few people
who have expressed an opinion on this. I have contacted our ADs and called
their attention to your compromise proposal, as a possible means of getting
IPP back on the standards track. They will ponder it over the week-end and
I hope to have some feedback from them in time for Tucson.
In the meantime, I have a suggestion for adding a few more values to our
current uri-security-supported attribute, which would provide exactly the
same information as has been proposed for the IPP Scheme Security parameter.
This adds values for DAA, TLS+DAA, and SSL3+DAA. I think we should add
these new values independently of where the IPP Scheme discussion ends up.
Here it is:
Section 4.4.2 uri-security-supported (1setOf type2 keyword)
'none': There are no secure communication channel protocols in use for
the given URI.
'daa': [DAA] authentication will be requested by the IPP Printer.
'tls': TLS 1.0 [TLS] is the secure communications channel protocol in
use for the given URI.
'tls-daa': TLS 1.0 [TLS] is the secure communications channel protocol in
use for the given URI.
In addition, [DAA] authentication will be requested by the IPP
printer.
'ssl3': SSL3 is the secure communications channel protocol in use for the
given URI.
(Note that SSL3 is proprietary, not a standard IETF protocol).
'ssl3-daa': SSL3 is the secure communications channel protocol in use for
the given URI.
In addition, [DAA] authentication will be requested by the IPP
Printer.
(Note that SSL3 is proprietary, not a standard IETF protocol).
Add reference to [DAA]:
[DAA]
Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen,
A., Sink, E., Stewart, L.,
An Extension to HTTP: Digest Access Authentication, January, 1997.
Carl-Uno
-----
> -----Original Message-----
> From: imcdonal@eso.mc.xerox.com [mailto:imcdonal@eso.mc.xerox.com]
> Sent: Wednesday, November 04, 1998 8:38 AM
> To: imcdonal@eso.mc.xerox.com; ipp@pwg.org; paulmo@microsoft.com
> Subject: RE: IPP> MOD - Client-side ONLY 'ipp:' scheme
>
>
> Hi Paul,
>
> I can see we're lost in the weeds here, again. The whole point
> is (with or without an 'ipp:' scheme) to make the landmark
> decision that we will NOT try to kludge security info as
> parameters into a URL for an IPP Printer.
>
> I suggested that we couple security to network directory services.
> No directory services, no strong security info available.
>
> Both Paul and Don has said SLPv1 (NOT SLPv2, in IESG Last Call)
> made a mistake in thinking that the registration record keys
> should be actual usable URL - well the whole darn WWW is
> based on exactly that premise, so we must be talking past
> each other here.
>
> Too bad - because I see IPP/1.0 dying fast in the marketplace
> because it never gets adopted onto the Internet 'standards
> track'. Resolving the security debate and the (separable)
> 'ipp:' scheme debate with the IESG seemed like a high
> priority to me. Good luck at the IETF Plenary in December.
> You'll all need it.
>
> Sorry my attempts at clarifications just muddied the waters,
> again.
>
> Cheers,
> - Ira McDonald (outside consultant at Xerox)
> High North Inc
> 906-494-2434
>