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

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

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

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Apr 11 2002 - 12:45:44 EDT

  • Next message: McDonald, Ira: "IPP> FW:Cert SNMP Update"

    Hi Ted,

    I agree with you and Tom.

    Since IPP/1.1 [RFC2910/2911] only makes TLS a SHOULD (not a MUST) for
    Printers, any non-admin extensions (like the 'ippget:' notification
    delivery method) should only make TLS a SHOULD

    Separately, although we didn't, we should have made the IPP Admin
    operations and IPP Job/Printer Set operations say MUST for TLS
    support (and SHOULD for TLS usage in all admin operations).

    Cheers,
    - Ira McDonald

    -----Original Message-----
    From: Ted Tronson [mailto:TTRONSON@novell.com]
    Sent: Thursday, April 11, 2002 9:23 AM
    To: hastings@cp10.es.xerox.com; ipp@pwg.org
    Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    Comments by April 15

    I'm with Tom on this. Most printers/print servers don't currently
    support TLS. So why would we want to force the printer/print server to
    implement TLS just for notification sake? If the print data can be raw.
    why do we have to force notification information to be "secure".

    Ted Tronson
    Sr. Software Engineer
    801-861-3338
    Novell, Inc., the leading provider of Net services software
    www.novell.com

    >>> "Hastings, Tom N" <hastings@cp10.es.xerox.com> 04/10/02 05:41PM
    >>>
    I would be willing to go along with REQUIRING TLS if the Printer
    supports
    (implements) notification. However, I suspect that this will
    discourage
    support of even the simple IPPGET. But more importantly, I don't
    understand
    why it is any more important to have security when you support IPPGET
    notification than if you don't support notification. In other words,
    I
    don't see why the security requirements should be higher for a Printer
    that
    supports notification than for one that doesn't.

    So I'd like to ask the IESG why we can't have the same TLS requirements
    for
    Printers that support (implement) Notification as ones that don't,
    since
    they approved RFC2910 with TLS only being RECOMMENDED for support
    (implementation).

    Tom

    -----Original Message-----
    From: Carl [mailto:carl@manros.com]
    Sent: Tuesday, April 09, 2002 19:48
    To: Hastings, Tom N
    Cc: ipp@pwg.org
    Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    Comments by April 15

    Tom,

    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.

    Are you prepared to go along with that (which I understand is already
    the
    case for IPPFAX)?

    Carl-Uno

    Carl-Uno Manros
    10701 S Eastern Ave #1117
    Henderson, NV 89052, USA
    Tel +1-702-617-9414
    Fax +1-702-617-9417
    Mob +1-310-251-7103
    Email carl@manros.com

    > -----Original Message-----
    > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
    Hastings,
    > Tom N
    > Sent: Tuesday, April 09, 2002 6:32 PM
    > To: Carl
    > Cc: ipp@pwg.org
    > Subject: RE: IPP> RE: Mandatory Delivery Method for Notifications -
    > Comments by April 15
    >
    >
    > Carl-Uno,
    >
    > I support the proposal to REQUIRE a Notification Delivery Method so
    that
    > interoperability between a conforming client and a conforming Printer
    is
    > enhanced for Notifications.
    >
    > I also support the proposal to make IPPGET be that REQUIRED
    > Delivery Method
    > by changing the IPP Notifications and Subscriptions document (which
    is an
    > OPTIONAL IPP extension document) in the following ways:
    >
    > 1. REQUIRE that a Printer support the IPPGET Delivery Method, if
    > the Printer
    > supports IPP Notifications.
    >
    > 2. REQUIRE that a client support the IPPGET Delivery Method, if
    > it supports
    > IPP Notifications.
    >
    > 3. RFC 2910 already RECOMMENDs that a Printer support TLS, so saying
    the
    > same thing in the Notifications and Subscriptions document would be
    > redundant, but we could still do that.
    >
    > Compared to our other two Delivery Methods (MAILTO and INDP), the
    IPPGET
    > Delivery Method has the following advantages:
    >
    > a. it is the easiest Delivery Method to support
    > b. it is in-band so it doesn't create any additional firewall
    problems
    > c. it is also useful for LAN job submission (with no firewall)
    > d. it doesn't create any more administrative problems
    > e. it is REQUIRED for IPPFAX conformance.
    > f. and doesn't have any SPAM problems (since the job submitter is
    polling
    > and/or keeping a channel open for notification events).
    >
    >
    > The IPPGET spec also should be changed:
    >
    > 4. We should also change the IPPGET spec itself from its current
    > "RECOMMENDED" to "REQUIRED" as a Delivery Method for an IPP Printer
    to
    > support.
    >
    > Tom
    >
    > -----Original Message-----
    > From: Carl [mailto:carl@manros.com]
    > Sent: Saturday, March 30, 2002 13:30
    > To: Carl; ipp@pwg.org
    > Subject: IPP> RE: Mandatory Delivery Method for Notifications -
    Comments
    > by April 15
    >
    >
    > Resend, with spelling corrected etc. The earlier message slipped
    > away before
    > I had finished it.
    >
    > All,
    >
    > Ned Freed communicated in an earlier message to the IPP WG, that the
    IESG
    > found it unacceptable that we had not choosen ONE mandatory
    > delivery method
    > for notifications. They would also like to see that delivery
    > method mandate
    > the use of security.
    >
    > As those of you who were around about two years ago remember, we
    could not
    > reach agreement about mandating any of the delivery methods.
    >
    > However, in the meantime the members of the IPPFAX project in the
    Printer
    > Working Group has reached an agreement that they will require all
    IPPFAX
    > implementions to implement the 'ippget' delivery method, and it also
    > requires support for TLS security.
    >
    > Hence, I would like to put up the following strawman proposal to
    > the IPP WG
    > members to satisfy the IESG comments:
    >
    > 1) Change the main Notifiction document to require that 'ippget'
    delivery
    > MUST be included for all notification implementations, but any of
    > the other
    > two methods can also be implemented as an option.
    > <draft-ietf-ipp-not-spec-08.txt>
    >
    > 2) Put that rule also into the three delivery method documents, so it
    is
    > crystal clear what the rule is.
    > <draft-ietf-ipp-notify-get-06.txt>
    > <draft-ietf-ipp-notify-mailto-04.txt>
    > <draft-ietf-ipp-indp-method-06.txt>
    >
    > 3) Further, in the 'ippget' delivery document, we specify that
    > TLS security
    > MUST be supported.
    > <draft-ietf-ipp-notify-get-06.txt>
    >
    > If we can reach agreement on this, I will instruct the IPP editor to
    > implement these changes.
    >
    > I would like to get your reactions back on this proposal no later
    > than April
    > 15, 2002.
    >
    > Carl-Uno Manros
    > Chair of IETF IPP WG
    >
    > 10701 S Eastern Ave #1117
    > Henderson, NV 89052, USA
    > Tel +1-702-617-9414
    > Fax +1-702-617-9417
    > Mob +1-310-251-7103
    > Email carl@manros.com
    >
    >



    This archive was generated by hypermail 2b29 : Thu Apr 11 2002 - 12:50:40 EDT