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

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

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

McDonald, Ira imcdonald at sharplabs.com
Mon Apr 15 14:30:54 EDT 2002


Hi,

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

Cheers,
- Ira McDonald

-----Original Message-----
From: ned.freed at mrochek.com [mailto:ned.freed at mrochek.com]
Sent: Friday, April 12, 2002 3:45 AM
To: Michael Sweet
Cc: Carl; Hastings, Tom N; ipp at 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>



More information about the Ipp mailing list