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