Forwarded message from Ned Freed.
Carl-Uno
-----Original Message-----
From: ned.freed at mrochek.com [mailto:ned.freed at mrochek.com]
Sent: Tuesday, April 16, 2002 10:50 PM
To: McDonald, Ira
Cc: 'ned.freed at mrochek.com'; Michael Sweet; Carl; Hastings, Tom N;
ipp at pwg.org
Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
Commen ts by April 15
> (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.
I don't think the two are necessarily comparable. ippget is used to poll the
printer, and I think a strong argument can be made that this should be
subject
to the same requirements as job submission.
idnp, on the other hand, is a mechanism where the printer connects to
clients.
The security considerations for such things are necessarily somewhat
different,
and the analogy to job submission doesn't necessarily apply.
Now, having said that, I also pointed out that these are at different stages
in
the process. ippget has not been to the IESG. I'm willing to try to get it
through without a mandatory to implement security mechanism on the basis of
the
analogy to job submission. I may or may not be successful at this -- as time
moves on the IESG is increasingly inclined to make security a mandatory to
implement part of any protocol proposal, regardless of past decisions for
similar protocols. Heck, if SMTP were being proposed as a new protocol today
there is zero chance it would be approved without mandatory to implement
security.
As for idnp, what I personally think about what's required can be inferred
from
the fact I let to go to the IESG without a mandatory to implement mechanism.
But what I think is no longer relevant. The IESG presently believes there
needs
to a mandatory to implement security scheme. (I did not write the text that
was
sent to the WG about this.) The WG either needs to provide one or else
provide
a persuasive argument as to why one isn't needed.
> (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?
Look in any mail user agent that submits messages and you'll see what needs
to
be added: SMTP server name/address for message submission, username to use
for
authentication, password to use, etc. Note that this is printer
configuration,
not per-job configuration.
> 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.
Er, actually, my AD review of this document only mentioned configuration in
passing. Nowhere did I say or even imply that this needs to be done in-band
or
even talked about in the mailto document. But you are looking at
configuration
issues in other contexts. Given that it seems important for you to
understand
what configuration is needed for this notification method to work.
> (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).
This is fine with me.
Ned