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.
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?
- 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.
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.
- 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.
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.
And, by the way, please remember that the appendix is not normative. It
does not change the specification. It "permits" and "prohibits" nothing.
- 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?
- 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 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.
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.
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.
- misleading text should be fixed, unworkable recommendations should be
removed.
Please offer whatever text changes you think helpful.
- 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.
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.
- 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?
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.
- 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.
- 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.)
- 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?
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?
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.
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.
> (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.
d/
----------
Dave Crocker <mailto:dave(_at_)tribalwise(_dot_)com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850