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

[Keith Moore <[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.

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