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.

    Carl-Uno

    -----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;
    ipp@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



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