Michael,
About your concerns about whether or not the mailto Delivery Method should
REQUIRE SMTP (forget about the issue of SASL)? Your concern is puzzling to
me, since:
1. The current mailto document contains the following statement in section 3
Model and Operation:
A Printer MUST support SMTP [RFC821], and it MAY support other email
protocols. A Printer MAY use additional services, such as SMTP delivery
status notification [RFC1891] or S/MIME encryption [RFC2633].
2. The current mailto document contains the following statement in section 3
Model and Operation:
If the Printer supports only SMTP, it MUST send the email message via SMTP.
If the Printer supports additional email protocols, it MUST determine the
protocol from the address part of the "notify-recipient-uri" attribute value
and then send the email message via the appropriate email protocol.
3. Table 1 has row 3 which says:
A Printer MUST support SMTP. It MAY support other email protocols.
4. Section 5.2.1 contains:
The Printer MAY support other syntax for the 'address part' if it supports
email protocols in addition to SMTP.
Do you object to any of these conformance statements in the current IPP
mailto spec? Should we change these statements in the current mailto spec?
Thanks,
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Wednesday, April 10, 2002 07:52
To: ipp at pwg.org
Subject: [Fwd: 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 at easysw.com>
Organization: Easy Software Products
To: ned.freed at mrochek.com
References:
<116DB56CD7DED511BC7800508B2CA5370A19B2 at mailsrvnt02.enet.sharplabs.com>
<01KG1RMP4ITI0000XB at mauve.mrochek.com> <3CA8C259.8070205 at easysw.com>
<01KG1V5PBXWE0000XB at mauve.mrochek.com>
ned.freed at 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 at easysw.com
Printing Software for UNIX http://www.easysw.com
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com