>Chances are that IESG won't allow a standards track RFC to incorporate
>the SSL3 protocol. It will have to reference the TLS protocol.
>Fortuantely, the TLS spec is essentally finished - the TLS WG has
>finished its internal Last Call and would appear to be ready to send
>the spec back to IESG. So I don't expect that referencing the TLS
>spec would delay adoption of IPP as a standard.
>
>Also, while it's technically feasible to always use TLS framing with
>IPP, it seems like it would be far better to define a SASL negotiation
>framework for HTTP, which could then negotiate TLS. SASL is already a
>Proposed Standard RFC, and is being retro-fitted into a number of
>existing apps protocols.
>
>Keith
>
Keith,
We will never get this project finished if we keep getting new or changed
security requirements from the Area Directors every week. This has already
held us up for an extra couple of months.
Can you confirm whether SASL now allows a user to negotiate that they do
NOT want to use security features as an option, otherwise I expect that we
do not want to touch it. An assumption in earlier discussions was that TLS
allowed for this, but apparently not any more after the latest IESG
intervention.
Can you PLEASE consider our project as a user of the IETF security
standards and when security comes up next in the IESG, in your role as our
project advisor, make it clear that we want to have one option which is
simply NO SECURITY (beyond RFC 2069, which we mandate support for in our
protocol specification).
Thanks,
Carl-Uno
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com