IPP> RE: Mandatory Delivery Method for Notifications - Comments by April 15

IPP> RE: Mandatory Delivery Method for Notifications - Comments by April 15

IPP> RE: Mandatory Delivery Method for Notifications - Comments by April 15

ned.freed at mrochek.com ned.freed at mrochek.com
Fri Apr 12 04:45:05 EDT 2002

> > 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.


More information about the Ipp mailing list