> > Your reply deviated on one point from my straw man proposal. The IESG would
> > like to see security mandated. In the case of 'ippget' that means MANDATORY
> > support for TLS (although it is RECOMMENDED in RFC 2910.
> > ...
> I think the IESG is off their rocker this time - mandatory support
> for TLS with notifications doesn't provide any appreciable improvement
> in security, especially since scenarios requiring the most
> confidentiality (notifications over the Internet) may not be able
> to support TLS upgrades due to firewall limitations.
Y'all need to read things a bit more carefully... Of course in order to
do that you need to have seen the messages I sent...
Anyway, nowhere did I say that IESG asked that TLS be required for
notifications in general. In fact neither the IESG nor I even mentioned TLS.
Nor did the IESG even consider the IPPGET or MAILTO schemes.
People are really getting wrapped around the axle here. So let's back
up and look at the picture from the top.
(0) Notifications are an OPTIONAL part of IPP. If you don't want to
implement notifications you don't have to. If you don't implement
notifications none of the rest of this applies to you.
(1) The IESG believes there has to be a way to assure interoperability between
clients and servers that do choose to implement notifications. The
simplest way to do this is to have a single mandatory to implement
notification scheme for all clients and server. There are other ways,
however, such as saying that all servers must support two schemes and
letting clients pick one of the two.
(2) Three notification schemes have been proposed. Each of these has different
characteristics and has different requirements. Additionally, each one
is at a different point in the process.
(a) INDP has been to the IESG and was returned to the WG. The IESG
believes there need to be a mandatory to implement security mechanism
in INDP.
(b) MAILTO has received AD review and the AD (me) believes further work is
needed. The AD believes S/MIME isn't especially appropriate in this
context. The AD also believes that it should be possible to use SASL
in this context and that the necessary infrastructure to do that needs
to be present. The AD also suggested, but did not insist on, mandating
SASL support.
(c) IPPGET has received AD review and is believed to be good to go
to the IESG as-is. But it won't be last called until the entire
notification package is complete and can be progressed as a unit.
I hope this clarifies the present situation somewhat.
Ned