IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

IPP Mail Archive: RE: IPP> RE: Mandatory Delivery Method for

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

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Apr 15 2002 - 14:30:54 EDT

  • Next message: Hastings, Tom N: "RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15"

    Hi,

    Ned - thanks for simplifying this discussion. My comments inline.

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
    Sent: Friday, April 12, 2002 3:45 AM
    To: Michael Sweet
    Cc: Carl; Hastings, Tom N; ipp@pwg.org
    Subject: Re: IPP> RE: Mandatory Delivery Method for Notifications -
    Comments by April 15

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

    <ira>
    Right - all the IPP Printer and IPP Client conformance requirements for
    notification should begin "An IPP Printer that supports notifications..."
    </ira>

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

    <ira>
    There is rough concensus (or something close) on this IPP list for the
    simple choice of one required delivery method for all clients/printers,
    the in-band 'ippget' method. The other methods ('mailto:' and 'indp:')
    would be MAY (not explicitly recommended) for IPP clients/printers.
    OK?
    </ira>

    (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

    <ira>
    (a) You are saying that INDP should make TLS (in-band IPP security) a MUST
        implement (and SHOULD use)?
        That's stronger than TLS for job submission is in RFC 2910/2911 (a
    SHOULD).
        Michael Sweet objected to this for 'ippget'. I think the same applies
    here.

    (b) You have referred to printer configuration needed for SMTP and SASL
    support.
        Could you describe some of the IPP Printer object attributes we should
    add?
        Michael Sweet's concern with initial configuration of authentication and
        security methods on an IPP Printer (especially an embedded system) is
        a good one. You threw it back to the WG, but IPP has NEVER said that
    all
        of the IPP Printer initial configuration can or should be done in-band.

    (c) I see WG concensus that TLS should be a SHOULD implement in 'ippget'.
        I suspect WG concensus that the 'ippget' method (_not_ a URL scheme)
        should be the mandatory one for IPP Printers or Clients that support
        IPP notifications to implement (but NOT to use - a client decision).
    </ira>



    This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 14:35:58 EDT