[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: The DSML 2.0 proposal is not yet transport independent.
I am explicitly proposing that we associate a message ID with each request
or response message within a given DSML 2.0 envelope. The message IDs are
integers in the range specified by RFC 2251.
A response to a request must have the same message ID as the request. When
a request message comes in, the transport provides the information on how
to direct the response back to the requestor, and this is out of band with
respect to DSML 2.0 flows. In the case of HTTP, the response is returned
on the same TCP connection. In the case of SMTP, the response is returned
to a particular email address. Other transports use other mechanisms. The
requesting principal must not reuse a message ID associated with an
outstanding request, i.e. a request for which no response has been
received. In the case of HTTP, this means that the requesting principal
must not reuse a message ID for an outstanding request on a given TCP
connection. In the case of SMTP, this means that the sender (using a
single return email address) must not reuse a message ID in a new request
if a previous request with the same message ID remains outstanding. This
is done to ensure that responses can be unambiguously associated with
requests, as described in RFC 2251.
-- John McGarvey
Jeff Parham <jeffparh@windows.microsoft.com> on 07/28/2001 06:35:17 AM
To: dsml@lists.oasis-open.org
cc:
Subject: RE: The DSML 2.0 proposal is not yet transport independent.
Support for an asynchronous model is a fine goal, but I don't believe we
can seriously consider it until someone puts a concrete proposal on the
table as to how to achieve this goal while not violating the rest of the
constraints (including having an agreed-upon, feature complete draft by
the end of August). One concern off the top of my head is that such a
proposal would seem to inherently require many more roundtrips to the
server.
Just to be clear, the RFC 2251 fidelity goal that we agreed upon
explicitly excluded this sort of asynchronous operation support, which was
to be considered seperately due to the controversy surrounding this issue.
-J
-----Original Message-----
From: Keith_Attenborough@lotus.com [mailto:Keith_Attenborough@lotus.com]
Sent: Friday, July 27, 2001 4:06 AM
To: dsml@lists.oasis-open.org
Subject: Re: The DSML 2.0 proposal is not yet transport independent.
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> To:
dsml@lists.oasis-open
07/27/01 01:28 AM .org
cc:
(bcc: Keith
Attenborough/CAM/Lotu
s)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC