Randy
Keith Moore wrote:
>
> > 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.
>
> The alternative, in this case, might be to get the project "finished"
> but have it going in a different direction from other HTTP-based
> protocols. If the IPP working group wants to explicitly decide to
> do that, that might be just fine, but I believe it's worth considering
> how to keep things coordinated.
>
> > Can you confirm whether SASL now allows a user to negotiate that they do
> > NOT want to use security features as an option.
>
> Of course it does. Both parties have to agree on the level of
> security used. Otherwise nobody would use it.
>
> With SASL, if a client doesn't want to use security, it simply
> doesn't issue the AUTH command. (Of course, the server could then
> deny access to any other commands with an insufficient authentication
> error.)
>
> > 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).
>
> This is fine with me, and as far as I know, it will be fine with
> the rest of IESG. As far as I'm concerned, SASL and/or TLS can
> be optional for an implementation.
>
> Keith