[Top] [All Lists]

Re: Fwd: I-D ACTION:draft-ietf-fax-esmtp-conneg-03.txt

2002-08-06 01:21:38


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

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

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


- 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.


Dave Crocker <mailto:dave(_at_)tribalwise(_dot_)com>
TribalWise, Inc. <>
tel +1.408.246.8253; fax +1.408.850.1850

<Prev in Thread] Current Thread [Next in Thread>