Re: Need new MEP for SMTP binding

 Chris,
 I respectfully disagree.
 One way is to specify fire-and-forget MEP (w/o ACKS) and
possibly add acknowledging on top of it. Simple fire-and-forget 
transports (like the email framework) will suffice for this.
 An other way is to specify a full one-way-with-ack MEP but then
you have to have more power in the transports, possibly having to 
extend the transports.
 Usually, one-way transports don't provide ACKs because once
there is provision for ACKs, it becomes very simple to provide
for full responses. This is why I'd rather see ACKing on top of
fire-and-forget MEP (specified once) than ACKing specified in
every fire-and-forget transport.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Thu, 14 Mar 2002, Christopher Ferris wrote:

 > but the one's with acks are oh so much more interesting:)
 > 
 > Jacek Kopecky wrote:
 > 
 > >  Oh, I forgot to add that I'd in fact like to see a one-way MEP, 
 > > but without the ACKs.
 > > 
 > >                    Jacek Kopecky
 > > 
 > >                    Senior Architect, Systinet (formerly Idoox)
 > >                    http://www.systinet.com/
 > > 
 > > 
 > > 
 > > On Thu, 14 Mar 2002, Mark Baker wrote:
 > > 
 > >  > Currently, the only MEP that's been defined is request/response.  In
 > >  > starting work on the SMTP protocol binding however, I feel that it's
 > >  > best to avoid request/response because SMTP is not a request/response
 > >  > protocol.  To do request/response with SMTP would necessarily be
 > >  > tunneling, and a major security issue.
 > >  > 
 > >  > Would there be any objections to us defining a new MEP that represents
 > >  > a one way message with hop-by-hop acknowledgement, like SMTP?  I see
 > >  > this as being reusable for any binding to a message queue based transfer
 > >  > protocol.
 > >  > 
 > >  > MB
 > >  > 
 > > 
 > > 
 > > 
 > 
 >

Received on Thursday, 14 March 2002 09:31:44 UTC