Re: The DSML 2.0 proposal is not yet transport independent.

[Keith_Attenborough@lotus.com]

Concur with John's remarks below.  Restricting implementation to a transport dependent approach seems unnecessarily restrictive.


Keith
------------------------------------------------------
Keith Attenborough, Product Manager (Domino Directory)
Lotus Development
email:  keith.attenborough@lotus.com
phone/fax:  617.693.9650 / 617.374.0111
cell:  617-834-6962

John McGarvey <mcgarvey@us.ibm.com> 07/27/01 01:28 AM

To:        dsml@lists.oasis-open.org         cc:        (bcc: Keith Attenborough/CAM/Lotus)         Subject:        The DSML 2.0 proposal is not yet transport independent.

At the face to face, we agreed that transport independence was a goal of
the DSML 2.0 effort.  However, it seems to me that the current proposal
does not satisfy that goal.  There is an assumption of a connection
oriented transport, with reliable delivery of messages which are guaranteed
to be in order.   I think we may want to support other forms of transport,
such as SMTP or various message oriented middleware products.  If an
envelope of requests is sent and an envelope of replies is received, the
sender is not dependent on a synchronous connection in order to reliably
associate the former with the latter.

Note that RFC2251 does not have this inherent limitation.  It associates a
message ID with each request and response.  I think that DSML 2.0 should do
the same.  This also cleans up a feature of the current design that seems
ugly to me, which is that the association of requests and responses is
positional within the envelope.

If connectionless transports are to be supported, the call-and-response
model is not the only processing model in which DSML 2.0 can be used.  A
series of requests can be queued up, and the responses may be received
asynchronously.  This processing model is also useful when a synchronous
connection is present: for example, LDAP over TCP supports this model
today, and therefore if we also adopt it in DSML 2 we preserve RFC2251
function with fidelity -- another goal we adopted at the face to face.

Further, if processing models other than call-and-response are supported,
there is no reason not to support unsolicited notifications, and no
additions to DSML 2.0 would be needed to support, for example, LCUP.  LCUP
relies on unsolicited notifications, and (when completed) it will be a very
useful means of ensuring a certain level of data consistency, so DSML 2.0
should not prevent its use.  If an application must operate in the
call-and-response model, that application can still poll periodically for
unsolicited notifications, where the polling frequency would correspond to
the level of data consistency required,

-- John McGarvey, IBM


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: dsml-request@lists.oasis-open.org