Keith,
Responding to those items that I can:
At 03:19 PM 8/5/2002 -0400, Keith Moore wrote:
- it is still overbroad, claiming applicability for general email
when it really works only for a limited subset of content
which has an obvious ordering relation for "quality".
Please feel free to provide real-world examples of usage that is likely to
be attempted and that will not work properly.
I have already done so, on multiple occasions. Perhaps we have different
ideas of what is 'likely' or what is 'real-world'. To me it seems likely
and consistent with the real world that senders will send around a wide
variety of content, that recipients will want to specify what kinds of
content they are willing to accept to keep from having their mailboxes
cluttered with useless content, and that senders will at least occasionally
want to specify that the message should not be delivered unless the recipient
is willing to accept the content. All of which is fine. But the assumption
that some intermediate MTA can then be expected to "transform" the sender's
content into something that the recipient is willing to accept - that does
not seem either fine, likely, or consistent with the real world.
At any rate, I don't think it's acceptable for an extension to cause
delivery failure or unrequested munging of messages even in 'unlikely'
cases - when whether the extension is employed isn't under control of
the sender.
perhaps illustrating this, all of the examples are for fax.
You believe that making examples be for something other than fax will
materially affect the adequacy of the normative specification?
I think that the examples being all fax illustrates that other cases
have not been adequately considered. Because as soon as you start to
consider other cases of how SMTP is used to send content, you find
that the existing proposal doesn't suffice.
- it still permits unauthorized parties to make arbitrary and
unspecified alterations to mail.
Sorry, no. It makes no alterations to the power of intermediaries. It
gives them better information, not different capabilities.
No, it's not just giving better information - because the SMTP client is
*required* to do something with that information. And there are words
and examples in the current proposal that have MTAs doing transformations
without any authorization from the sender or recipient to do so.
In any event, the "permissions" assigned to intermediaries are a matter of
administration policy, not technical specification. If an administrative
authority does not want to permit use of this option, it will not use it.
I disagree that it is appropriate to assign such authority to administrators.
Certainly the transformations will not be performed (i.e. the software will
not be installed) without the administrators' consent, but the authority
to transform a particular message needs to be given by the user, not the
administrator. The administrator is rarely in a position to know whether
the transformation is appropriate.
- worse, the new version permits unauthorized parties to make
arbitrary assertions of recipient capabilities in the absence
of explicit information.
That is not what the discussion says. It describes a way of having the
receiving SMTP server take on the responsibilities for matching
capabilities that already reside with the sending SMTP server.
I think you have that backwards, or something. It doesn't make any
sense to me.
Remember that these servers about which you are so suspicious already have
"control" over the semantics of the recipient's address. You can't get
more powerful than that.
Yes, but the function of SMTP intermediaries has generally been limited to
relaying of the message intact - not performing arbitrary transformations on
the message. We've accepted that minor transformations might be necessary
in a gateway situation, but we've never blessed the idea that arbitrary MTAs
should change the content of messages within the SMTP world.
And, by the way, please remember that the appendix is not normative. It
does not change the specification. It "permits" and "prohibits" nothing.
Perhaps it is only misleading or confusing, but it still affects the
quality of the document.
- it still allows SMTP servers to make assertions of recipient capabilities
without actual knowledge of those capabilities.
What is the problem this causes? How does it make this service fail?
If the message is not delivered intact when sender did not request
transformations and the receiver did not request transformations,
that's a failure. SMTP isn't supposed to mung messages.
- I still think overloading of RCPT is a pessimal way to do this
A number of separate analyses of the design choices suggest pretty strongly
that a separate command is actually worse than an RCPT parameter.
A lot of that analysis depends on how you assume that this is used - and
in particular whether it is used only by special-purpose devices or if
it's used between UAs in general. I don't share those assumptions.
A separate command changes the SMTP state machine. That is not a minor
thing. An example of the impact of this is probable failure in getting
through some firewalls.
A separate command doesn't have to change the state machine in the sense
that it adds either new states or new state transitions - and I'd argue
that the command should not do so. I'll grant that firewalls might have
trouble with a new command. But I've also seen firewalls have trouble
with new parameters, so I don't know how much the existence of firewalls
favors a new parameter over a new command.
And RCPT with CONNEG most definitely changes the state machine of the sender,
even in cases where the sender sends at most one RCPT per session, because
there is at least new one state transition necessary for "cannot adapt
content to recipient's capabilities". And in general MTAs will need to deal
with the multiple RCPT cases, which adds a fair amount of complexity to the
sender's state machine.
since the command will often need to be issued twice anyway -
Your use of the word "often" is contrary to the likelihoods expected by
others.
Yes, I understand that, though I think "some others" would be more accurate.
People will disagree about what they think are probable usage scenarios.
recommendations for near-term publication:
- this feature should be renamed and the document reworded to make it
clear that it is fax-specific rather than general purpose.
There is nothing in the normative text that is fax specific.
The expectation that it's possible to downgrade to a common format is
specific to fax. It might work with voice mail assuming no proprietary
codecs were used, but that seems like a stretch. Also, the assumptions
about how this will be used, that governed design decisions like
overloading RCPT vs a new command, seem to be heavily based on fax.
- misleading text should be fixed, unworkable recommendations should be
removed.
Please offer whatever text changes you think helpful.
To some degree I have tried to do so already, though perhaps not bracketed
as such. But I don't think we're quite to the point we can solve the
problems by mere wordsmithing.
- the document should be published as experimental rather than on the
standards track, since it doesn't meet the requirements for proposed
standard.
You have so far offered no details of failure scenarios that warrant the
fears you are expressing.
That's false. I've done so on multiple occasions.
things that need to be fixed before the document should be considered
as standards-track:
- needs to be examined for a wide range of content
Again, you are offering such a generic suggestion, there is no way to know
what problems you fear or how to satisfy them.
Well, I've already stated them on multiple occasions. And when the problem
is one of a failure to consider some important factor early in the design
phase (as this seems to be), the fix is to reconsider that factor.
Until that is done, all protocol fixes will be suspect.
- needs to have a well-defined protocol by which senders can request
conneg "convert-or-fail" semantics on a per-message, and probably
per-bodypart, basis. if they are not requested, such semantics
must not be applied.
So, SMTP is not appropriate to standardize without having submit and pop
also specified at the same time?
I didn't say anything about the mechanism, and in fact I expect that
senders would specify transformation permissions in message and body part
headers. I don't know if it's necessary to standardize the mechanisms
by which recipients specify conneg parameters, but I do think it's
necessary that recipients consent to such rather than having some
unrelated other party make assertions on their behalf.
That is a barrier that is equivalent to the one you wish to impose before
standardizing the current option. It means that you believe that an entire
suite of specifications must be offered at the same time, before any one of
the components may be standardized. This is contrary to typical IETF
practise.
I think you have this backwards. It's contrary to IETF practice to
standardize a protocol that has known technical omissions - which this
proposal certainly does. Your claim that it's appropriate to advance
an incompete specification because 'an entire suite of specifications
must be offered at the same time' is baseless and not supported by
either the process standards or by 'typical IETF practise'.
- needs to explicitly specify which conversion algorithms are permissible
and how new conversion standards may be added, since there can be
multiple ways to perform a conversion and some are worse than others.
Conneg is not new to this option. The requirement that you wish to impose
has not been imposed on other uses of Conneg. It appears that you are
confusing a carriage scenario with a conversion mechanism.
The difference here, I believe, is that with CONNEG over SMTP arbitrary
SMTP servers are both allowed and expected *as a matter of protocol
conformance* to perform conversions without consent of either sender or
receiver.
- needs to state that conneg features are only advertised with the
recipient's consent and control
If you have text to suggest for the draft, please offer it, for working
group review. (It would have been nice to have had that text offered
earlier. The danger is that there will be a running stream of
non-normative modifications of this nature.)
I could offer text on this one specific point, but there are other points
for which offering text seems counterproductive. In general, it seems
premature to offer text when we don't even have a vague agreement on what
specific mechanisms (e.g. for indicating consent) should look like.
- needs to state exactly which parties are authorized to perform
conversion.
Huh?
- needs to prevent multiple conversions.
What does that mean? What problems are you concerned about?
this is mentioned below in the detailed comments.
problem: this proposal doesn't provide any way to "enforce" content
negotiation past a single hop.
You believe that there does not already exist a requirement for relays to
enforce content quality? You believe that the concern about enforcing
content quality is new to this option?
I don't know what it means to "enforce content quality", partially since
I think it's the job of MTAs to "maintain content integrity" and partially
since the MTA has no notion of what "quality" means to the recipient.
I believe there is now a requirement for relays to relay mail intact - in
the current world, any relay that doesn't do so is nonstandard. The proposed
extension tries to change that.
nit: It is not clear whether it is desirable for the server to give
CONNEG errors priority over all other sources of error.
The nature of any complex system is that there can be multiple errors at
approximately the same time.
Hence your concern for prioritization of error reporting is not specific to
this option.
No, but the proposal says that it MUST take precedence, and that seems
overbroad. I did attempt to suggest better wording.
problem: the client cannot be compelled to perform transformations that
are impossible or for which the client lacks the capability. no client
can reasonably convert video to audio.
Please provide a detailed example of Conneg use that could lead to the
problem of needing to convert video to audio.
Someone sends mail with a video attachment to a recipient that advertises
that it can only accept audio. Somebody (whether the sender or an
intermediate MTA) adds the CONNEG option for that recipient. The conversion
is not possible, yet it is required by the current spec.
(2) Common Content
For a single ESMTP session, issue RCPT commands that obtain
content capabilities information for each recipient. With the
DATA command, send the best content form that can be processed by
ALL of the recipients. Some recipients will receive content that
is below their best capabilities. However this approach also
consumes the least bandwidth and has the fewest cross-network
protocol exchanges
problem: this scenario does not work because the sender has no way to know a
priori whether it is possible to produce a common form that is acceptable
to all recipients.
Feel free to provide a real-world example of being unable to produce a
common form within the context of conneg capabilities information. You
have raised this concern before and we have, so far, seen nothing concrete
to substantiate the concern.
As far as I can tell, this is only because you believe that nobody will try
to use CONNEG except in those cases that you've anticipated or where it has
been observed to work well. It's not as if I haven't supplied concrete
examples as to how things can fail, but you dismiss them as not 'real-world'.
In my "real world" users' interests and habits are quite diverse and are
not so predictable.
At any rate, making things work in your idea of the real world is not
sufficient. Email must function properly as a matter of design, so that
if the specifications are followed then predictable and useful behavior
is assured. Speculation about what users are likely to do and what
administrators are likely to impose is not sufficient.
Keith