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

Carl carl at manros.com
Wed Apr 17 07:34:04 EDT 2002

Forwarded message from Ned Freed.


-----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
>     Michael Sweet objected to this for 'ippget'.  I think the same applies

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
to the same requirements as job submission.

idnp, on the other hand, is a mechanism where the printer connects to
The security considerations for such things are necessarily somewhat
and the analogy to job submission doesn't necessarily apply.

Now, having said that, I also pointed out that these are at different stages
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
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

As for idnp, what I personally think about what's required can be inferred
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
to a mandatory to implement security scheme. (I did not write the text that
sent to the WG about this.) The WG either needs to provide one or else
a persuasive argument as to why one isn't needed.

> (b) You have referred to printer configuration needed for SMTP and SASL
>     Could you describe some of the IPP Printer object attributes we should

Look in any mail user agent that submits messages and you'll see what needs
be added: SMTP server name/address for message submission, username to use
authentication, password to use, etc. Note that this is printer
not per-job configuration.

>     Michael Sweet's concern with initial configuration of authentication
>     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
>     of the IPP Printer initial configuration can or should be done

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
even talked about in the mailto document. But you are looking at
issues in other contexts. Given that it seems important for you to
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.


More information about the Ipp mailing list