Minutes of TBTF Email Binding Meeting, 14 January 2002.

Attendees

Placement of content?

Nilo does not want the current eMail Binding Proposal placed within the
Primer.  Any binding illustrating the Binding Framework cannot stand alone
within the Primer, because it does not match the Primer's style and
objective.  Nilo plans on adding some narrative text to the Primer
describing the Binding Framework.  The placement of the new eMail Binding is
still to be decided.

***** Open issue - Editors/TBTF - Placement of the non-normative eMail
Binding to be determined at a higher level (aka David/WG)

The spec has 2 audiences(Glen's take):
1) one will use the spec as a framework to author extensions and perhaps
   bindings
2) one will utilize those extensions and bindings to implement apps

Noah - Other content in the future may pose similar questions. Such content
    does not belong in the primer, and this second transport binding may not
    belong in primer - we will need to address at some point.

Intro and review attached SMTP w/ MDN Binding

The proposed binding used the default HTTP Binding content structure and
applied it to SMTP w/ MDN's (to be called eMail Binding)

Summary of key points and next steps:

1) Change title of binding to eMail Binding - SMTP Binding is misleading,
   other protocols involved
2) Take out MDN usage and extra sessions
3) Continue using Single Request Response MEP with a Correlation Feature
   (One Way MEP creation to be driven outside this project)
4) Nilo to create narrative Primer text to describe the Transport Binding
   Framework
5) David/WG to be asked about content placement in spec (via TBTF) and the
   need for a One Way MEP.
6) Format content in xml get copy from Editors (Marc Hadley)

Detailed listing of meeting discussion:

Participants opening comments:

Glen - A good start - generally right direction
Not explicitly an SMTP Binding but an rfc 2822 binding along with POP/IMAP
for receipt
Getting into QoS is too far - back in July - Ugo - simple  version to be
included later - take out MDN's
Reframe rfc 2822, one way MEP, layer correlation, rr -- does not reflect
same mep as http, we can live with that
In summary - scale back - mep one way - keep it simple

Noah - caveat to Glen's points, agree with most - but concerned with only
one way mep
State what properties are available, such as correlation id, props available
at end points and use existing srr mep
sample binding - closer binding , correlation, need to do more thinking
A MIME binding may satisfy partial needs of an upper layer requirement for
correlation
Frame as eMail/MIME/rfc822 Binding

Jacek -
strong feelings against named SMTP Binding proposal
1) We want to do an email binding ok, but don't call it an SMTP binding
2) Alternative, show framework on a different protocol - mail is wrong
choice - email usage is addresses easily, off line processing storage and
later processed
Correlation rr is dangerous, that is not what email is for,  if we want to
show off framework use beep or other protocol
Could live with simple one way named (rfc2822)eMail Binding not smtp

Noah - email in reality will be used, many people use email and fax, could
be used in order processing marketing, 
agree in delays issue, correlating responses to request is important
Regarding related meps, we may need a rapid rr, general rr, 
A Request/Response processed over 5 days changes behavior of MEP.
Jacek - MEP could be illustrated using simple email reply with added
correlation feature, mep using correlation

Stu
- like Noah - leaning toward email binding, illustrative rr over one way or
srr mep and correlation(header) - 

1)one way mep creation (normative)
2) one way if http binding has a one way - yes to noah if http can get away
without having a one way mep

End of opening comments, begin general discussion(rough content):
============================================================

Stu - smtp can support srr, http has a connection, with email some piece of
code needs to be written to take properties from mail headers, store
correlation id's

Noah - want reply to, msg id, to be handled at smtp level

Jacek - why not use msg id, when available

Noah - Usage model of ordering books, correlation can be used to accept
responses 

Glen - multi bindings per protocol

Noah - Correlation could be illustrated via - msg id with subject lines,
with header to maximize value of example

Glen - bindings can take advantage or header

Noah - preference in email headers, fields, 3rd binding in envelope

Nilo - using it in email header would show correlation via email, but
various reply

Noah - one outbound one return, same case, We should mirror http binding

Jacek - ? when saying email binding with correlation, one way or srr

Noah - srr - using correlation msg id

Jacek - split one way, correlation

Noah - mep same with note, slower not immediate rr 

srr - 1 Stu, 1 hmm, 1 noah

1 way - 1 Jacek, 1 Glen not a big deal, 

issue - one way - requirement of WG?

srr - in reply to message id, reply to header
fire and forget - looses interest, no need to deal with time out feature -
application design level

stu - name should be soap over internet mail, email binding

jacek - Only detail at receiving node is that the node will receive email,
    no need to elaborate on POP3 details, keep it simple.