headers
Hiroshi Tamura | 15 Jul 2003 07:43
Picon

Re: draft-ietf-fax-esmtp-conneg-08.txt


To SMTP experts,

I asked your comments as below, but nothing.
Please comment NOW if there are things to suggest/discuss about the document.
If not, FAX WG will request the IESG consideration again, sooner or later.

Thanks in advance.

Best Regards,
--
Hiroshi Tamura, Co-chair of IETF-FAX WG

From: Hiroshi Tamura <tamura <at> toda.ricoh.co.jp>
Subject: draft-ietf-fax-esmtp-conneg-08.txt
Date: Thu, 26 Jun 2003 08:52:26 +0900 (JST)

> 
> To SMTP experts,
> 
> FAX WG did the WG Last Call of the I-D below and it was complete.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-08.txt
> 
> At San Francisco's meeting, our WG agreed to ask for comments
> from SMTP experts after the WG LC.
> In fact, last year, you had a good review for the previous I-D.
> 
> If there are issues to say, please comment.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 15 Jul 2003 09:20

Re: draft-ietf-fax-esmtp-conneg-08.txt


Folks,

HT> I asked your comments as below, but nothing.
HT> Please comment NOW if there are things to suggest/discuss about the document.
HT> If not, FAX WG will request the IESG consideration again, sooner or later.
...
>> http://www.ietf.org/internet-drafts/draft-ietf-fax-esmtp-conneg-08.txt

I would like to strongly add to Tamura-san's request.  The proposed SMTP
extension adds to a variety of other mechanisms for doing capabilities
negotiation.  This extension is to make that negotiation feasible
through email transport, and has been enhanced to include an
authorization mechanism from the sender.

Please at least do a quick review and comment to the list, to provide an
explicit, documented sanity check from the email community.

d/
--
 Dave Crocker <mailto:dcrocker <at> brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
Permalink | Reply | 0 comments |
headers
Valdis.Kletnieks | 15 Jul 2003 10:12
Picon
Favicon

Re: draft-ietf-fax-esmtp-conneg-08.txt

On Tue, 15 Jul 2003 14:43:43 +0900, Hiroshi Tamura said:

> I asked your comments as below, but nothing.
> Please comment NOW if there are things to suggest/discuss about the document.
> If not, FAX WG will request the IESG consideration again, sooner or later.

I suspect the flame wars on this topic from July of last year when the -03 draft was raised
have left a bad taste in everybody's mouth, and nobody wants to get involved again.

There was serious disagreement on the SMTP side of the fence as to whether it
was possible to implement this correctly - my re-reading of such mail as I saved
indicates a number of people who were quite resistant to the idea of an automatic
downgrading without any indication that information had been lost (for instance,
consider the case of a color fax downgraded to B/W - if the loss of color is significant,
this could be a problem.

In addition, it was quite unclear how this would interact with RFC1847-style signatures.

I have *NOT* checked if the -08 draft adequately addresses these issues.
Permalink | Reply | 0 comments |
headers
Dave Crocker | 15 Jul 2003 23:34

Re: draft-ietf-fax-esmtp-conneg-08.txt


Valdis,

VKve> I have *NOT* checked if the -08 draft adequately addresses these issues.

Please do.

We think it does.

d/
--
 Dave Crocker <mailto:dcrocker <at> brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
Permalink | Reply | 0 comments |
headers
Pete Resnick | 16 Jul 2003 13:24

Re: draft-ietf-fax-esmtp-conneg-08.txt


On 7/15/03 at 2:43 PM +0900, Hiroshi Tamura wrote:

>I asked your comments as below, but nothing.
>Please comment NOW if there are things to suggest/discuss about the document.
>If not, FAX WG will request the IESG consideration again, sooner or later.

Why is the CONPERM command necessary? Isn't putting Content-Convert 
parts in a message implicit permission to do such transformations? Or 
is CONPERM really just signalling the server to go look inside the 
message?

Other than that, it looks like an OK document to me.

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 0 comments |
headers
Dave Crocker | 16 Jul 2003 14:08

Re: draft-ietf-fax-esmtp-conneg-08.txt


Pete,

PR> Why is the CONPERM command necessary? Isn't putting Content-Convert 
PR> parts in a message implicit permission to do such transformations? Or
PR> is CONPERM really just signalling the server to go look inside the 
PR> message?

Without the ESMTP option, SMTP relays must look into the message
content, to determine whether conversion is permitted.  Hence we decided
to put a  basic permission mechanisn into the explicit transfer
mechanism, with the fine-grained permission detail in the content.

PR> Other than that, it looks like an OK document to me.

thanks!

d/
--
 Dave Crocker <mailto:dcrocker <at> brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
Permalink | Reply | 0 comments |
headers
Vaudreuil, Greg M (Greg | 23 Jul 2003 18:27
Picon
Favicon

RE: BDAT, RFC 3030 protocol clarification?


Thank you for your comments.

I have substituted your example text. It illustrates several subtle points worth calling out. 

As I studied section 2, I don't see an easy way to separate the pipelining and non-pilelining text without
duplicating or completely rewriting text.  I am reluctant to perform major surgury as this is the third
edition of the document.  I don't recall at this point which words were extensively debated and carefully
chosen and which reflect authors choice.  I would also like it to remain structurally the same so readers
using DIFF can easily find the changes.

Is this a major concern?  If now, I'd like to avoid the re-write.

Greg V.

-----Original Message-----
From: Matti Aarnio [mailto:mea+ietf-smtp <at> nic.funet.fi]
Sent: Thursday, June 19, 2003 8:25 AM
To: Vaudreuil, Greg M (Greg)
Cc: ietf-smtp <at> imc.org
Subject: Re: BDAT, RFC 3030 protocol clarification?

On Wed, Jun 18, 2003 at 09:29:59AM -0500, Vaudreuil, Greg M (Greg) wrote:
> I hope the below referenced Internet-draft has captured the discussion
> we have been having.  Specific comments would be welcome, preferably in
> time to turn a new revision before the IETF meeting.
> 
> Greg V.

I have two things:
(Continue reading)

Permalink | Reply | 19 comments |
headers
Keith Moore | 26 Jul 2003 06:36
Picon

Re: draft-ietf-fax-esmtp-conneg-08.txt


Sorry to take so long, but I was finally able to read this.

I believe the basic design of this extension is sound, in that it 
requires both consent from the originator and knowledge of recipient
capabilities before an intermediary can perform conversion, it allows 
the originator to each specify what conversions may be performed, 
and it provides an indication to the recipient when conversions were 
performed, and by whom.

1. My biggest concern is that for a message for which CONPERM is
asserted, either the absence of an unbroken chain of CONPERM-capable
relays or the absence of CONNEG for a recipient is (apparently) treated
as an indication that the recipient cannot accept any kind of content -
forcing a delivery failure.  (Either that or the assertion of CONPERM is
not only "permission" from the sender for intermediaries to perform
content conversion, but also a request that the sender not deliver
messages which are not known to be acceptable to the recipient, which
seems like an inappropriate binding of two unrelated requests.)  

This is not backward-compatible with the installed base. The extention
should allow sending of the same message to multiple recipients, some of
which can be sent through CONPERM-capable servers and some of which
cannot, some of which support CONNEG and some of which do not, without
requiring the originating MTA or UA to put each recipient's message in a
separate envelope and without requiring the originating MTA or UA to
know in advance which recipients' delivery paths support CONPERM/CONNEG
and which do not.  It is especially unreasonable to bounce a message in
the absence of CONNEG given that there is currently no standard
mechanism by which a recipient can indicate his CONNEG
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Moore | 26 Jul 2003 18:01
Picon

Re: draft-ietf-fax-esmtp-conneg-08.txt


> PR> Why is the CONPERM command necessary? Isn't putting Content-Convert 
> PR> parts in a message implicit permission to do such transformations? Or
> PR> is CONPERM really just signalling the server to go look inside the 
> PR> message?
> 
> Without the ESMTP option, SMTP relays must look into the message
> content, to determine whether conversion is permitted.  Hence we decided
> to put a  basic permission mechanisn into the explicit transfer
> mechanism, with the fine-grained permission detail in the content.

also, messages can be forwarded, but the permission granted by the original
sender to perform conversions might not be desired by the party forwarding the
message.  

(having the content-convert information in the message body at all seems
likely to cause problems later - ideally it should be entirely in the
envelope.  however I understand why it's in the message body.)
Permalink | Reply | 0 comments |

Gmane