headers
Michael D'Errico | 6 Jun 1994 06:55

Re: Binary Comments... (and more)


You wrote:
> Hmm. Well, I think you need to reexamine some of your conclusions here.

Yes, you are right.  I got confused by your statement:

    On the other hand, I don't think it is too much to ask that BDAT always
    succeed: If a server doesn't like the BDAT command, it can always ignore
    the data and signal the error at the end of the chunk. And if it always
    succeeds, why even bother to send the 354 response to the BDAT initially?

I incorrectly interpreted this as "the BDAT command will always return '250 Ok'"
instead of "the BDAT command will always successfully read the following chunk
of data."  I then went on from there....

I re-read everything and I think I'm back in alignment -- sorry for the noise.

Anybody planning to implement such a beast?  I'll be able to shortly....

Regarding the checkpoint/restart issue, Keith Moore said:

    If the BDAT response were to return an appropriate magic cookie
    (e.g. the offset into the queued message file after storing that
    chunk), it wouldn't be too hard to do checkpoint/restart also.

The problem I see with this is that if we specify what the server must return
as the "magic cookie" then there is a possibility that some servers will not
be able to generate the information.  For instance, my MTA stores messages in
not one, but two files (one for the header and one for the body).  In this
case how would you define "offset into the queued message file?"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Keith Moore | 8 Jun 1994 02:45
Picon

Re: Binary Comments... (and more)

> 
> Regarding the checkpoint/restart issue, Keith Moore said:
> 
>     If the BDAT response were to return an appropriate magic cookie
>     (e.g. the offset into the queued message file after storing that
>     chunk), it wouldn't be too hard to do checkpoint/restart also.
> 
> The problem I see with this is that if we specify what the server must 
> return as the "magic cookie" then there is a possibility that some 
> servers will not be able to generate the information.  For instance, 
> my MTA stores messages in not one, but two files (one for the header 
> and one for the body).  In this case how would you define "offset into 
> the queued message file?"
> 
> I think it would be better to allow the server to return whatever it deems
> necessary, and then have the client spit it back on restart.  But all of
> this probably belongs in a separate checkpoint/restart extension document
> anyway.

This is what I had in mind.  The format of the magic cookie should be known
only to the server-MTA.  So in the case of your MTA the cookie format could
be: 1 bit for which file is being appended to, and N-1 bits for the offset
into that file.

Keith
Permalink | Reply | 0 comments |
headers
IESG Secretary | 9 Jun 1994 21:49
Picon
Picon

Protocol Action: SMTP Service Extension Documents to Draft Standard


The IESG has approved the following three Internet-Drafts:

  o "SMTP Service Extensions"
    <draft-ietf-smtpext-extensions-01.txt>
  o "SMTP Service Extension for 8bit-MIMEtransport"
    <draft-ietf-smtpex-8bitmime-01.txt>
  o "SMTP Service Extension for Message Size Declaration"
    <draft-ietf-smtpext-size-01.txt>

as Draft Standards. These documents are the product of the Internet
Mail Extensions Working Group.  The IESG contact person is Erik
Huizer.

Technical Summary

  This series of documents define a framework for extending the SMTP
  service and an initial set of optional services including 8bit
  transport for MIME messages and message size declaration.

  The extensions mechanism defines a means whereby a server SMTP can
  inform a client SMTP as to the service extensions it supports.  With
  the knowledge of the servers capabilities a client can, without
  negotiation, use enhanced services.

  The 8bit extensions document defines an extension to the SMTP service
  whereby content bodies consisting of a MIME message containing arbitrary
  octet-aligned material may be exchanged.  Note that this extension does
  *not* eliminate the possibility of an SMTP server limiting line length;
  servers are free to implement this extension, but nevertheless set a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 17 Jun 1994 21:16
Picon
Picon

I-D ACTION:draft-vaudreuil-smtp-binary-04.txt

Note:  This announcement is being re-sent.

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories.                                                               

       Title     : SMTP Service Extensions for Transmission of Large and 
                   Binary MIME Messages                                    
       Author(s) : G. Vaudreuil
       Filename  : draft-vaudreuil-smtp-binary-04.txt
       Pages     : 6
       Date      : 06/14/1994

This memo defines two extensions to the SMTP service.  The first service 
enables a SMTP client and server to negotiate the use of an alternate DATA 
command "BDAT" for efficiently sending large MIME messages.  The second 
extension takes advantage of the BDAT command to permit the negotiated 
sending of unencoded binary data.                                          

Internet-Drafts are available by anonymous FTP.  Login with the	
username "anonymous" and password "guest".  After logging in,
Type "cd internet-drafts".
     "get draft-vaudreuil-smtp-binary-04.txt".

Internet-Drafts directories are located at:	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane