IPP Mail Archive: [Fwd: Re: IPP> RE: Mandatory Delivery Meth

IPP Mail Archive: [Fwd: Re: IPP> RE: Mandatory Delivery Meth

[Fwd: Re: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15]

From: Michael Sweet (mike@easysw.com)
Date: Wed Apr 10 2002 - 10:52:13 EDT

  • Next message: Dennis Carney: "RE: IPP> RE: Mandatory Delivery Method for Notifications - Commen ts by April 15"

    In case my reply to his comments didn't make it to the list...

    -------- Original Message --------
    Subject: Re: IPP> RE: Mandatory Delivery Method for Notifications -
    Commen ts by April 15
    Date: Mon, 01 Apr 2002 17:35:00 -0500
    From: Michael Sweet <mike@easysw.com>
    Organization: Easy Software Products
    To: ned.freed@mrochek.com
    References:
    <116DB56CD7DED511BC7800508B2CA5370A19B2@mailsrvnt02.enet.sharplabs.com>
    <01KG1RMP4ITI0000XB@mauve.mrochek.com> <3CA8C259.8070205@easysw.com>
    <01KG1V5PBXWE0000XB@mauve.mrochek.com>

    ned.freed@mrochek.com wrote:
    > ...
    > First of all, you are confusing mandatory to implement with mandatory to
    > use. We are only concerned with the former, not the latter.

    Ahem, I'm not confusing things; I am pointing out that on many systems
    (let's say, Linux or any other UNIX using sendmail, postfix, etc.) the
    underlying IPP implementation may not have any control over the mail
    transport. In fact, many networks do *not* use SMTP for mail transport.
    (I'm not justifying or endorsing this, I'm just making an honest
    observation based on 8 years of writing printing software for UNIX)

    > ...
    > Third, even if you are justified in considering an implementation that
    > only implements local posting without SMTP as legitimate, it really
    > doesn't fall within the IETF's purview to standardize such things.

    We are using the "mailto" scheme, defined by RFC 2368, as the
    identifier for a notification recipient. The mailto scheme does
    not specify the transport being used, but merely defines how the
    URI is formatted and how it applies to standard mail headers.

    As an implementation requirement, all we should feel justified to
    state is something like "mailto implementations that use SMTP to
    deliver notification messages SHOULD support SASL and ...".
    However, nothing SASL provides will prevent SPAM/DoS attacks
    through an IPP server. *That* is the main concern for the mailto
    scheme, since any (physical/network) security issues are the users'
    responsibility.

    ....

    My beef with all of this is simple: we develop CUPS, which is based
    on IPP. As we implement IPP Notifications in CUPS 1.2, mailto is
    one of the methods we will support. If the specification states that
    we MUST use SMTP and MUST support SASL, then 1) the implementation
    will become an order of magnitude larger, 2) the configuration
    and support of the implementation will become an order of magnitude
    larger, and 3) a large fraction of our customers will not be able to
    use mailto notification. (!$@&!^#!)

    In short, any mention of SMTP or SASL should be worded as an
    implementation guide/recommendation, and not as a requirement
    of the mailto spec.

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    

    -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com



    This archive was generated by hypermail 2b29 : Wed Apr 10 2002 - 10:52:44 EDT