IPP> MOD - Client-side ONLY 'ipp:' scheme + Proposal for addi tional uri-security-supported values

IPP> MOD - Client-side ONLY 'ipp:' scheme + Proposal for addi tional uri-security-supported values

IPP> MOD - Client-side ONLY 'ipp:' scheme + Proposal for addi tional uri-security-supported values

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Wed Nov 4 12:44:06 EST 1998


Ira,

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 at eso.mc.xerox.com [mailto:imcdonal at eso.mc.xerox.com]
> Sent: Wednesday, November 04, 1998 8:38 AM
> To: imcdonal at eso.mc.xerox.com; ipp at pwg.org; paulmo at 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 
> 



More information about the Ipp mailing list