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

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

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

From: Carl (carl@manros.com)
Date: Wed Apr 17 2002 - 07:34:04 EDT

  • Next message: McDonald, Ira: "IPP> FW: New I-D for Internationalized Resource Identifiers"

    Forwarded message from Ned Freed.


    -----Original Message-----
    From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
    Sent: Tuesday, April 16, 2002 10:50 PM
    To: McDonald, Ira
    Cc: 'ned.freed@mrochek.com'; Michael Sweet; Carl; Hastings, Tom N;
    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.


    This archive was generated by hypermail 2b29 : Wed Apr 17 2002 - 07:34:41 EDT