At 14:27 15/11/2004, Martin Stecher wrote:
jfc,
>
> 1. resuming interrupted sending. Probably several cases and ways.
I understand that this could be:
An MTA sends a message to another MTA. Due to network problems
the connection aborts while sending the email in the DATA command.
"Resuming the interrupted sending" will allow to start a second
attempt and only send the part of the message that the recno
didn't get in the first run?
To me this seems to require additional commands in the SMTP dialog.
Should we propose OPES use cases for SMTP additions that are not
yet defined? I think we should do better without those.
Martin,
the interest of OPES/SMTP is that it can provide services on top of SMTP
without changing SMPT (or this would not be an OPES whatever this may mean)
but an ESMTP additional feature.
The use as I see for example for South Pacific Islands, ships, space craft,
mobiles etc. one OPESMTP filter on each end of the link and two servers.
They notes the headers and forget them once the transfer is completed. When
an uncompleted mail is resent the sending side OPES sends a message to the
OPES on the receiving end to reinject the part it already has.
This same mechanism could also be used to send a multiple copy mail only once.
> 2. virtual transfers. When the same mail is sent to several
> recipients, the
> first copy could be transfered with meta data defining the others to
> rebuild on the arriving MTA.
Agree with Tony. This is is already part of SMTP (multiple "rcpt to").
I am not sure as I am not SMTP header. But I do not think so as this is not
UA or MTA related but bandwidth management related. The group of SMTP hosts
to be supported (filtered) should be reported to the OPES system.
>3. compression during transfer
>
If this should be something like a Transfer-Encoding, it is outside
of OPES. If you think about a content encoding for compression, it is
another example of case 1-6 "Format Conversion".
Do you agree?
Again, I am not versed enough in SMTPing to fully understand the question.
Better I give and example and take back the SoPac case. The point is to
enhance the satellite link usage or provide delayed delivery in case of
temporary failures. Compression may be considered only between the sending
and receiving ends. This is just on a network segment. This could be used
for many other applications, but SMTP is a much demanded one with its own
specifics. Example: right now on the main list is discussed the case of 10
M Yahoo attachments with a usual limit of 2 M. The transfer of a large
attachment could be negotiated vs compression, delayed transfer at off-peak
hours, routing through another link, delivery to another equivalent mail
box (using for example a low priority MX address, etc.)
I fully agree that we do not want to propose changes to SMTP (all the more
than I consider SMTP being overloaded as the reason of spam). I am not
against enhancing SMTP in "polluting" the SMTP demands with good OPES
solutions, SMTP designers could decide to include in their specs. But we
should adopt the position that SMTP is used in application as an
asynchronous signaling protocol with very limited features being used, to
trigger different services that could be loaded as private OPES. So the
least we are involved with SMTP advanced features probably the best?
jfc