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

[Dave Crocker <[e-mail]>]

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:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]