--On Wednesday, 03 July, 2002 20:56 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)com
wrote:
(4) A general concern about the many possible
uses for this mechanism that has all of us engaging in futile
speculation and which cannot possibly be dealt sensibly with
in a specification without actual implementation and use
experience.
That is a reasonable position. But I suggest that it implies
either that this material should go to Experimental, rather than
Proposed, or that the mechanism should be defined as applicable
to the cases that are understood and expanded only when the
implications of that expansion are better understood. Or...
--On Wednesday, 03 July, 2002 21:35 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)com
wrote:
The only clearly valid argument I've seen so far for removing
REQUIRED is that it may not really be needed and things that
aren't needed should not be there. But whether or not it is
needed is really a question for the WG. Perhaps those who
actually plan to implement CONNEG clients could comment on
whether or not they view REQUIRED as something they need.
I, at least, would find such comments helpful. But I'd also
like to hear comments from at least one person responsible for a
general-purpose MTA (as distinct from a fax-over-email engine)
who expects to implement this feature and how they propose to do
so and how this feature fits in.
--On Wednesday, 03 July, 2002 20:25 -0700 Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> wrote:
At 08:32 PM 7/3/2002 -0400, John C Klensin wrote:
I don't either. My concern is that it is fairly poorly
defined in relay scenarios
What needs to be defined that is not defined?
This is a hop-by-hop protocol, just like all of SMTP. If
there is relaying with CONNEG support, then CONNEG is used at
each hop. Just like for DSN.
To give just one example, suppose that CONNEG=OPTIONAL is
specified for one or more recipients. Now assume a three-hop
(two relay) scenario in which the first relay accepts CONNEG but
the second does not support it. That implies that the
originating MTA (SMTP client) is going to get back the error
response in email. To the degree to which the specification
implies that it is going to make content decisions based on what
the server tells it, we are now in big trouble.
Or one can look at the perhaps less-complex case in which
CONNEG=REQUIRED is specified. Same two-hop case. In any normal
scenario (see below), the first hop SMTP server can't possibly
know what capabilities the client of the destination SMTP server
might have at the time the message reaches it. So it can't
return capabilities, which I think means we have just invented a
"no relay" capability.
and it strikes me that the idea of having an SMTP option that
is prohibited from use in relaying is rather more massively
significant than whether this particular option will work well
in relaying circumstances.
First, we already have several similar requirements as a result
of permitting certain behavior only from originating
(submission) and final destination SMTPs. Second, as outlined
above, CONNEG=REQUIRED may itself be a "no relay" requirement in
the general case.
That still leaves "one virtual fax, one recipient" (and, by
definition, one destination) as a probably-very common case,
given real-world fax behavior today.
One might also want to consider that the concept of obtaining
per-recipient capabilities rather naturally suggests a
tendency to do per-recipient tailoring of content.
One does not need any history of fax to note the likelihood of
the one-to-one case being dominant. One might even suspect
that it is inherent.
Once again, if this were restricted to fax, where we understand
behavior and likely use, I would have substantially no problem
with it (this still isn't how I would have designed the
facility, but the fax WG should have the appropriate
discretion). If it were restricted to "fax-like" situations, we
could be having a discussion about how to define "fax-like", but
the same principles and conclusions would, I think, apply. My
difficulties start with the assertion that this is a
general-purpose email facility, rather than a fax one, with the
expectation of multiple recipients, relays, gateways, etc. And,
for that purpose, I'd be a lot happier with serious review, and
comments about likely implementation issues, from the
conventional general-purpose SMTP user and implementor
community, not just a fax-focused WG.
john