Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 12 Aug 2003 14:45:09 -0400
List-Id: <ietf-smtp.imc.org>

> KM> 1. My biggest concern is that for a message for which CONPERM is
> KM> asserted, either the absence of an unbroken chain of
> KM> CONPERM-capable relays or the absence of CONNEG for a recipient is
> KM> (apparently) treated as an indication that the recipient cannot
> KM> accept any kind of content - forcing a delivery failure.
> 
> The real question about the draft is: What is the purpose of the
> proposed mechanism?
> 
> As specified, the mechanism is intended to provide a specific
> quality-of-service capability.  QOS pertains to a "enforcement".

Then I must question whether such an extension is actually appropriate.
To me the extension as proposed is technically unsound, or at the very
least, it grossly overstates its applicability by claiming to be a
general purpose conversion negotiation mechanism. I've tried to make
suggestions which would make it technically saner and more broadly
applicable.

> If the sender is only concerned about communicating their desires to
> the recipient, they can do that. They simply include the appropriate
> Content-Convert headers, without using the SMTP extension.

For that matter, recipients don't need sender authorization in order
to perform conversions.  Recipients are free to perform whatever
conversions they want and suffer the benefits or consequences.
(assuming, of course, that the message is actually delivered to them) 
So that clearly is not the purpose of this extension.  However the
extension as currently defined can prevent delivery of messages that
would be usable by the recipient if delivered.

> If the sender is concerned about obtaining capabilities information
> about the recipient, they can do that too, using RFC 3297, "Content
> Negotiation for Messaging Services based on Email".

Right, but this is slow and unreliable, and not suitable for
intermediaries, and so not relevant here.

> If you believe there is a specific scenario that needs to be
> supported, but cannot be, I am not understanding what it is.

The scenario is that someone wants to send a message without specific
knowledge of the recipient's capabilities, and without specific
knowledge of intermediary capabilities, and allow for the potential for
intermediaries to convert that message as necessary to accomodate the
recipient's needs, but maximize the chance that the message will be
delivered - rather than having the message delivery fail for lack of an
intermediary that supports the required extension, conversion, or
whatever.

> Please clarify, and indicate what is the basis for needing it. Let's
> keep in mind that adding options mean adding complexity. So, the
> reason for the variations needs to be compelling.

No, the reason for defining an extension that is entirely incompatble
with the huge installed base needs to be compelling.  

> KM> (Either that or the assertion of CONPERM is
> KM> not only "permission" from the sender for intermediaries to
> KM> perform content conversion, but also a request that the sender not
> KM> deliver messages which are not known to be acceptable to the
> KM> recipient, which seems like an inappropriate binding of two
> KM> unrelated requests.)
> 
> By contrast, I believe they are two sides of the same capability.
> 
> The permission being given is constrained. In fact, that is the reason
> for putting this into SMTP, rather than simply using the
> Content-Convert MIME header, by itself.

It seems entirely appropriate to put some constraints on the ability of
intermediaries to perform conversions.  However I believe the
constraints, as currently defined, are highly undesirable for the vast
majority of SMTP users. 

There are lots of reasons to not simply use the Content-Convert header
as an indicator that conversion is permitted - one being that it makes
much more sense to associate the conversion permission with message
transmission than to make it an attribute of the message itself.

> KM> This is not backward-compatible with the installed base.
> 
> Options often are not backward compatible.  That is why they are
> options.

Let me be clearer then.  This option will harm SMTP mail by adding
complexity to the mail system to add functionality which is, for the
vast majority of purposes, undesirable and harmful.

> KM>  The extention
> KM> should allow sending of the same message to multiple recipients,
> KM> some of which can be sent through CONPERM-capable servers and some
> KM> of which cannot, some of which support CONNEG and some of which do
> KM> not,
> 
> You are calling for a mechanism that is significantly more
> complicated. Hence is a requirement for community consensus about
> needing that extra capability.

Let's back up.  There are two broad requirements for a Proposed Standard
protocol - one is community consensus, the other is technical soundness.
These are independent of one another - a protocol that is shown to not
be technically sound is not suitable for PS even if there is consensus
support for it.   

I should make clear that my review had three purposes:  
First, to make an assertion about the lack of technical soundness of the
current proposal.  Second, to indicate that I'm withholding my support
toward a consensus for the current version of this document for
technical reasons. Third, to make suggestions for changes (that I think
are NOT significantly more complicated than the current proposal) that
would improve the technical soundness of the proposal, allow it to be
more generally applicable, and allow me (and I suspect others) to
support it.

You are correct that the changes I've suggested, if included, would also
require community consensus for the document to be approved as PS. 
However community consensus is not required on findings about technical
soundness.

> As you note, the mechanism you are
> calling for can already be emulated by breaking the transmission down
> into smaller groups of addressees, according to the choices you want
> to apply.
>
> This means that your concern is really about efficiency. Optimizing
> "efficiency" of such a mechanism is appropriate only if this
> characteristic of the mechanism will greatly affect performance. We
> have no indication that this is an issue, here.

Given that you have yet to make a convincing case that this option is
desirable at all, debating the efficiency of the option seems a bit
premature.  But even so, efficiency is not the only issue.  Even if
there is only one recipient per envelope, a sender using this option is
forced to choose between letting intermediaries perform conversions (but
risking delivery failure of messages that would be readable by the
recipient) on one hand, and not allowing intermediaries to
perform conversions on the other.  The sender does not have the
knowledge to know which choice will maximize the potential for delivery
of a readable message. 

You could of course claim that this is also an efficiency issue - after
all, the sender can always send two messages, one with the option and
one without - but this just seems silly when a small change of the rules
will allow the sender to safely grant conversion permission without fear
that this will cause unnecessary delivery failures.

> KM> The current definition of this extension makes it essentially
> KM> useless when attempting to send mail to any recipient that is not
> KM> known in advance to support CONPERM/CONNEG.
> 
> That's right. Much like the long-standing problem of sending a MIME
> attachment for a vcard, if you do not already know that they support
> vcard. Or for sending any MIME type, if you do not already know it is
> supported.

It's not the same at all.  The worst thing that should happen when
you attach a vCard is a bit of wasted bandwidth and a bit of information
that the recipient cannot use.  Similarly for multipart/alternative.

By contrast the worst thing that can happen when you use CONPERM as
currently defined is that a message that could otherwise have been read
by the recipient is needlessly bounced.

> So, really, you are focusing on the general problem of knowing whether
> the SMTP relay chain supports particular SMTP options. That is a
> laudable goal, but it is not one we are trying to solve.

No, that's not what I'm focusing on.  I'm focusing on whether CONPERM is
defined appropriately given the inherent limitations of SMTP and SMTP
option negotiation.

> KM> I believe the absence of CONNEG information for a recipient should
> KM> be treated as if the recipient can support any kind of content, or
> KM> (more realistically) that the recipient will either perform any
> KM> needed conversions or bounce the message.
> 
> Now I am even more confused. What you describe is what we already
> have, today. Certainly we do not need an option to provide a mechanism
> that is already in use?

You are confusing the assertion of CONPERM by the sender with the
presence/absence of CONNEG by the recipient.   What I'm describing is
(IMHO) the proper behavior for a SMTP client which has accepted CONPERM
responsibility when attempting to relay a message to a recipient that
does not support CONNEG.

> If you believe that the value-add is to have the sender indicate what
> conversions are "permitted" then the sender should use only the
> Content-Convert headers, without the SMTP Conperm/Conneg mechanism.

I don't think this would be sufficient, because I don't think conversion
permission should be an attribute of the message - it should be an
attribute of the envelope.  And clearly the purpose of CONPERM is to
extend limited permission to intermediaries (not recipients) to perform
conversions - recipients have always been able to do what they wished
with messages independent of sender permission.

> 
> KM> 2. Another concern is the handling of messages when the relay
> KM> which is expected to provide a conversion (in that it has both
> KM> CONPERM and CONNEG for the recipients) is unable to perform one or
> KM> more of the conversions required.  I believe the appropriate
> KM> behavior is for a relay to perform those conversions which it is
> KM> able to perform, and to relay the message (with CONPERM asserted,
> KM> if possible) to the next hop.  It is possible that subsequent hops
> KM> may be able to perform the other conversions.
> 
> You are suggesting a rather sophisticated environment, with
> incremental conversion.  It sounds quite clever.
> 
> However trying to support such a loosely-coupled, "accidental" mixture
> of services, properly, is far beyond our abilities to specify and
> certainly beyond any demonstrated need.

The service you are supporting is already "accidental", especially
against a backdrop of (I'm guessing) tens of thousands of deployed
SMTP servers that don't support it and have negative incentive to do so.
By allowing each body part to be converted independently, I'm trying to
increase the probability that the service will do something useful in
practice rather than simply bounce messages.  

And as implied in my earlier message, I also believe that it's more
realistic to assume that the intermediaries closer to the sender are
able to adapt the sender's wierd formats to more generic ones, and those
closer to the recipient are able to adapt the generic formats to the
recipient's wierd ones, than to assume that the first intermediary that
supports CONNEG can adapt all of the sender's wierd formats to whatever
the recipient can use.

> KM> Indeed, it is in a sender's interest to have his outbound
> KM> mail transmitted through relays that can convert the sender's
> KM> unique formats to more commonly-used formats; and it is in the
> KM> recipient's interests to have his inbound mail MX'ed through
> KM> relays that are capable of converting common formats to those
> KM> which he can use.   We should not expect all conversions to be
> KM> performed at the same hop.
> 
> Right now, Internet mail does not permit conversions to be done
> anywhere in the relay chain. I suggest we try to support the simple
> scenario -- which has already turned out to be far more complex than
> we first thought necessary -- before trying to solve the general case,
> especially since we have no demonstrated need for it.

The scenario you propose is only slightly simpler, but far less
functional.  And since you mentioned demonstrated need, I have yet to
see a demonstrated need for an extension that acts as you propose.

> KM> I attempted to do a case analysis for what a sender should do for
> KM> various combinations of sender and receiver CONNEG and CONPERM
> KM> capabilities. Notation is as follows:
> 
> Keith, this is a wonderful bit of explanatory material and I think it
> will help quite a lot to add it to the text.  Thanks!
> 
> (Obviously, I disagree with some of its content, but that disagreement
> is entirely separate from appreciating the nature of the exercise and
> appreciating its general utility. We can haggle over the details,
> separately.)

You are welcome, and it will be interesting to see the precise cases
where we disagree.  I hope it will illuminate the discussion.

> KM> 5. Interaction with critical-content indication (RFC 3459) needs
> KM> to be defined.
> 
> Oh boy. You raise an important point. However I really, seriously,
> strongly would like to find a way to avoid having options specify
> interactions with other options, as much as possible.

I certainly agree with the general sentiment.  But I don't think it's
reasonable in this case to ignore critical content indication.

> At the least, it raises both a concern about creating a "precedence
> hierarchy" for options", and a concern about constantly retro-fitting
> options to account for new options. grrrr. mumble. fooey!
> 
> So, here is what I am going to suggest:
> 
> CONPERM/CONNEG concern the presence and enforcement of an SMTP
> service. Rejection of the message occurs when that service cannot be
> continued through the delivery path. In the context of that
> description of a hop-by-hop service enforcement, the MIME body-part
> information, contained in Content-Convert headers, is secondary.
> 
> By contrast, the Critical Content enhancement to the Content-Handling
> MIME header is a label about a final-delivery disposition of the
> content.

To me it seems important to not bounce a message merely because a
non-critical content cannot be converted. 

> They have some relationship, but mostly they are separate.  If and
> when we see some actual experience with interactions between them, it
> will be worth considering adding text to cover the issue.

It seems disingeneous to insist on actual experience for features you
don't want to include, and not insist on actual experience for features
you want.  We never have actual experience for new features.  We have to
resort to analysis, and sometimes intiution, to decide whether we think
they'll work well.  In some cases analysis works better than actual
experience because there are some kinds of actual experience - e.g.
widespread failure of mail delivery - that we wish to avoid.

> KM> b. Section 1 states that no MDNs will be issued for successful
> KM> conversion
> 
> Given that it says what is *not* done, it will probably be best to
> dodge this debate by changing the reference to say "...that no
> notification is issued...".

works for me.

> KM> d. Servers asserting CONPERM without being able to perform
> KM> conversions:
> KM>    While there are certainly cases where this is appropriate, they
> KM>    seem like fairly narrow cases.  For instance, any MTA that has
> KM>    mail forwarding capability probably cannot be certain that any
> KM>    necessary conversions can be performed.
> 
> I don't understand what point you are making or what change you are
> suggesting for the specification.

I suggest that a statement be added indicating that this is appropriate
only in narrow cases, and that an example or two be added to illustrate
what such cases might be.

> KM> f. In a couple of places, this spec attempts to impose
> KM> requirements on
> KM>    servers that are not in-scope for this spec.
> 
> Where and how?

I think I mentioned these specifically in the detailed change
suggestions.

> KM> h. if the Content-Convert field is omitted, it should be
> KM> explicitly
> KM>    stated that no conversions are authorized by the sender.
> 
> If there is no Content-Convert field, what is the point of having
> Conperm/Conneg?

you could have CONPERM on a message transmission while still not having
content-convert in each body part.

> KM> i. Question: Is the Content-Features field applicable to all kinds
> KM> of
> KM>    content that might be converted?  Should section 8 be a SHOULD?
> 
> Please explain.

I'm wondering if there are kinds of conversions that could not
adequately be conveyed in content-features.  It's just a question, I
really don't know the answer.

Date: Tue, 12 Aug 2003 11:28:26 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt
Sender: [email-masked]

>> Right now, Internet mail does not permit conversions to be
>> done anywhere in the relay chain.
JCK> Either I misunderstand the assertion above, or it is incorrect.
JCK> ESTMP options --especially 8BITMIME-- quite explicitly permit 
JCK> (indeed, require, if the message cannot be forwarded in 8bit 
JCK> form and is not to be bounced) conversions in the relay chain. 

There were two problems with my original phrasing.

One is that I meant to say "there is currently no way to indicate
permission to convert".

The other is that these are content (representation) conversions,
whereas something like 8bitmime is transfer/encoding conversion. Very
different.

VKve> It's interesting you use the 'vcard' example - I have actually had a *lot* of
VKve> problems with sites that will *BOUNCE* mail if they detect a PGP signature,
VKve> due to broken implementations that think all 'application/*' are viruses.

I'm afraid that I do not see how a series of seriously broken
implementation and operations decisions has anything to do with this
proposal.

VKve> Keith is saying "It's broken on the 822 level, let's not do it on the 821 level too".

And I'm still not seeing what is meant by "broken on the 822 level".

>> Right now, Internet mail does not permit conversions to be done anywhere
>> in the relay chain. I suggest we try to support the simple scenario --
>> which has already turned out to be far more complex than we first
>> thought necessary -- before trying to solve the general case, especially
>> since we have no demonstrated need for it.

VKve> The fact it's a lot more complicated for the simple case should give you pause....

Again, I apologise, but I do not understand your point or, for that
matter, what you are suggesting.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

Date: Tue, 12 Aug 2003 13:33:49 -0400
From: John C Klensin <[email-masked]>
To: Dave Crocker <[email-masked]>, Keith Moore <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt
Sender: [email-masked]

--On Tuesday, 12 August, 2003 09:07 -0700 Dave Crocker 
<[email-masked]> wrote:

> Right now, Internet mail does not permit conversions to be
> done anywhere in the relay chain. I suggest we try to support
> the simple scenario -- which has already turned out to be far
> more complex than we first thought necessary -- before trying
> to solve the general case, especially since we have no
> demonstrated need for it.

Dave,

Either I misunderstand the assertion above, or it is incorrect. 
ESTMP options --especially 8BITMIME-- quite explicitly permit 
(indeed, require, if the message cannot be forwarded in 8bit 
form and is not to be bounced) conversions in the relay chain. 
Whether that is actually material to "conneg", or to the 
discussion you and Keith are having, is another matter, but we 
certainly do permit such conversions.

regards,
   john

To: Dave Crocker <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt 
From: [email-masked]
Date: Tue, 12 Aug 2003 12:43:33 -0400
Sender: [email-masked]

--==_Exmh_-1535904846P
Content-Type: text/plain; charset=us-ascii

On Tue, 12 Aug 2003 09:07:07 PDT, Dave Crocker said:

> KM> The current definition of this extension makes it essentially useless
> KM> when attempting to send mail to any recipient that is not known in
> KM> advance to support CONPERM/CONNEG.
> 
> That's right. Much like the long-standing problem of sending a MIME
> attachment for a vcard, if you do not already know that they support
> vcard. Or for sending any MIME type, if you do not already know it is
> supported.
> 
> So, really, you are focusing on the general problem of knowing whether
> the SMTP relay chain supports particular SMTP options. That is a
> laudable goal, but it is not one we are trying to solve.

I think Keith's point is that failing to solve that goal results in brain damage.

It's interesting you use the 'vcard' example - I have actually had a *lot* of
problems with sites that will *BOUNCE* mail if they detect a PGP signature,
due to broken implementations that think all 'application/*' are viruses.

Keith is saying "It's broken on the 822 level, let's not do it on the 821 level too".

> Right now, Internet mail does not permit conversions to be done anywhere
> in the relay chain. I suggest we try to support the simple scenario --
> which has already turned out to be far more complex than we first
> thought necessary -- before trying to solve the general case, especially
> since we have no demonstrated need for it.

The fact it's a lot more complicated for the simple case should give you pause....

--==_Exmh_-1535904846P
Content-Type: application/pgp-signature

--==_Exmh_-1535904846P--

Date: Tue, 12 Aug 2003 09:07:07 -0700
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Keith Moore <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: draft-ietf-fax-esmtp-conneg-08.txt
Sender: [email-masked]

Keith,

Thanks for the thoughtful and extensive explanation of your concerns.
The following responds to the discussion section of your note.

Separately, I'll start formulating a revised draft, including your
suggestions.

KM> 1. My biggest concern is that for a message for which CONPERM is
KM> asserted, either the absence of an unbroken chain of CONPERM-capable
KM> relays or the absence of CONNEG for a recipient is (apparently) treated
KM> as an indication that the recipient cannot accept any kind of content -
KM> forcing a delivery failure.

The real question about the draft is: What is the purpose of the
proposed mechanism?

As specified, the mechanism is intended to provide a specific
quality-of-service capability.  QOS pertains to a "enforcement".

If the sender is only concerned about communicating their desires to the
recipient, they can do that. They simply include the appropriate
Content-Convert headers, without using the SMTP extension.

If the sender is concerned about obtaining capabilities information
about the recipient, they can do that too, using RFC 3297, "Content
Negotiation for Messaging Services based on Email".

If you believe there is a specific scenario that needs to be supported,
but cannot be, I am not understanding what it is.

Please clarify, and indicate what is the basis for needing it. Let's
keep in mind that adding options mean adding complexity. So, the reason
for the variations needs to be compelling.

KM> (Either that or the assertion of CONPERM is
KM> not only "permission" from the sender for intermediaries to perform
KM> content conversion, but also a request that the sender not deliver
KM> messages which are not known to be acceptable to the recipient, which
KM> seems like an inappropriate binding of two unrelated requests.)

By contrast, I believe they are two sides of the same capability.

The permission being given is constrained. In fact, that is the reason
for putting this into SMTP, rather than simply using the Content-Convert
MIME header, by itself.

KM> This is not backward-compatible with the installed base.

Options often are not backward compatible.  That is why they are
options.

KM>  The extention
KM> should allow sending of the same message to multiple recipients, some of
KM> which can be sent through CONPERM-capable servers and some of which
KM> cannot, some of which support CONNEG and some of which do not,

You are calling for a mechanism that is significantly more complicated.
Hence is a requirement for community consensus about needing that extra
capability. As you note, the mechanism you are calling for can
already be emulated by breaking the transmission down into smaller
groups of addressees, according to the choices you want to apply.

This means that your concern is really about efficiency. Optimizing
"efficiency" of such a mechanism is appropriate only if this
characteristic of the mechanism will greatly affect performance. We have
no indication that this is an issue, here.

KM> The current definition of this extension makes it essentially useless
KM> when attempting to send mail to any recipient that is not known in
KM> advance to support CONPERM/CONNEG.

That's right. Much like the long-standing problem of sending a MIME
attachment for a vcard, if you do not already know that they support
vcard. Or for sending any MIME type, if you do not already know it is
supported.

So, really, you are focusing on the general problem of knowing whether
the SMTP relay chain supports particular SMTP options. That is a
laudable goal, but it is not one we are trying to solve.

KM> I believe the absence of CONNEG information for a recipient should be
KM> treated as if the recipient can support any kind of content, or (more
KM> realistically) that the recipient will either perform any needed
KM> conversions or bounce the message.

Now I am even more confused. What you describe is what we already have,
today. Certainly we do not need an option to provide a mechanism that is
already in use?

If you believe that the value-add is to have the sender indicate what
conversions are "permitted" then the sender should use only the
Content-Convert headers, without the SMTP Conperm/Conneg mechanism.

KM> 2. Another concern is the handling of messages when the relay which is
KM> expected to provide a conversion (in that it has both CONPERM and
KM> CONNEG for the recipients) is unable to perform one or more of the
KM> conversions required.  I believe the appropriate behavior is for a
KM> relay to perform those conversions which it is able to perform,
KM> and to relay the message (with CONPERM asserted, if possible) to 
KM> the next hop.  It is possible that subsequent hops may be able to 
KM> perform the other conversions.

You are suggesting a rather sophisticated environment, with incremental
conversion.  It sounds quite clever.

However trying to support such a loosely-coupled, "accidental" mixture
of services, properly, is far beyond our abilities to specify and
certainly beyond any demonstrated need.

KM> Indeed, it is in a sender's interest to have his outbound
KM> mail transmitted through relays that can convert the sender's unique
KM> formats to more commonly-used formats; and it is in the recipient's
KM> interests to have his inbound mail MX'ed through relays that are capable
KM> of converting common formats to those which he can use.   We should not
KM> expect all conversions to be performed at the same hop.

Right now, Internet mail does not permit conversions to be done anywhere
in the relay chain. I suggest we try to support the simple scenario --
which has already turned out to be far more complex than we first
thought necessary -- before trying to solve the general case, especially
since we have no demonstrated need for it.

KM> Perhaps it is assumed that all conversions will be performed "close to"
KM> the recipient (perhaps because there are no mechanisms for
KM> propagating CONNEG upstream) and thus that there is unlikely to be an
KM> opportunity for subsequent conversion.  If this is being assumed it
KM> should be stated explicitly.

I think you make a very good point. The question really hinges on the
propagation of the CONNEG information. It seems likely that it will not
propagate far. Few hops. So, yes, I think it would help people's
understanding of the specification to add some non-normative discussion
of this.

KM> I attempted to do a case analysis for what a sender should do for
KM> various combinations of sender and receiver CONNEG and CONPERM
KM> capabilities. Notation is as follows:

Keith, this is a wonderful bit of explanatory material and I think it
will help quite a lot to add it to the text.  Thanks!

(Obviously, I disagree with some of its content, but that disagreement
is entirely separate from appreciating the nature of the exercise and
appreciating its general utility. We can haggle over the details,
separately.)

KM> 3. I believe that multiple conversions of a single body part should be
KM> discouraged, especially if any of those conversions is lossy, because
KM> multiple lossy conversions can be very destructive to the content.

Again, excellent point and one that should be added to the document.

KM> 4. There are several types of conversion failures that might require
KM> some difference either in handling or in the error code reported:

ditto.

KM> 5. Interaction with critical-content indication (RFC 3459) needs to be
KM> defined.

Oh boy. You raise an important point. However I really, seriously,
strongly would like to find a way to avoid having options specify
interactions with other options, as much as possible.

At the least, it raises both a concern about creating a "precedence
hierarchy" for options", and a concern about constantly retro-fitting
options to account for new options. grrrr. mumble. fooey!

So, here is what I am going to suggest:

CONPERM/CONNEG concern the presence and enforcement of an SMTP service.
Rejection of the message occurs when that service cannot be continued
through the delivery path. In the context of that description of a
hop-by-hop service enforcement, the MIME body-part information,
contained in Content-Convert headers, is secondary.

By contrast, the Critical Content enhancement to the Content-Handling
MIME header is a label about a final-delivery disposition of the
content.

They have some relationship, but mostly they are separate.  If and when
we see some actual experience with interactions between them, it will be
worth considering adding text to cover the issue.

KM> a. Terminology:  For consistency with other email specifications,
KM>    and to avoid the potential for people (including authors?) to
KM>    assume that this extension is only for email-to-device applications,

The language was chosen to make sure that non-email reception was
supportable. That is, it was meant to be *more* general, not less.

However I do believe that some changes can be made, to use the word
'recipient' more often, and that it will improve the overall tone of the
document.

KM> b. Section 1 states that no MDNs will be issued for successful conversion

Given that it says what is *not* done, it will probably be best to dodge
this debate by changing the reference to say "...that no notification is
issued...".

KM> c. Use of Content-Previous by recipient-authorized converters:
KM>    Is it permissible for converters authorized by a recipient and acting
KM>    on a recipient's behalf (which do not require sender permission)
KM>    to use Content-Previous to label such conversions and communicate
KM>    them to the recipient?

yes.

KM> d. Servers asserting CONPERM without being able to perform conversions:
KM>    While there are certainly cases where this is appropriate, they
KM>    seem like fairly narrow cases.  For instance, any MTA that has
KM>    mail forwarding capability probably cannot be certain that any
KM>    necessary conversions can be performed.

I don't understand what point you are making or what change you are
suggesting for the specification.

KM> e. NIT.  Please use "MAIL FROM" rather than "MAIL-FROM" and "RCPT TO"
KM>    rather than "RCPT-TO" for consistency with RFC[2]821.

ack.

KM> f. In a couple of places, this spec attempts to impose requirements on
KM>    servers that are not in-scope for this spec.

Where and how?

KM> g. section 5.2 states that the client SHOULD convert the data to the
KM>    "highest" level of capability of the server.  I believe this should
KM>    instead state that the client SHOULD use the "least lossy"
KM>    conversion available.
KM>  For example, there is no point in converting
KM>    to a high-resolution image format supported by the client
KM>    when a lower-resolution format is sufficient to convey the image
KM>    with the same degree of loss.

This seems like a useful point to add to the text.  Thanks.

KM> h. if the Content-Convert field is omitted, it should be explicitly
KM>    stated that no conversions are authorized by the sender.

If there is no Content-Convert field, what is the point of having
Conperm/Conneg?

KM> i. Question: Is the Content-Features field applicable to all kinds of
KM>    content that might be converted?  Should section 8 be a SHOULD?

Please explain.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>