[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.
Can you define the changes to the XML representation required to support your proposal? Is it just the association of an integer XML-attribute with each request and response element? Is this XML-attribute optional?
How does the client determine the message IDs to stamp on its requests, esp. for something like the SMTP transport where the message IDs must presumably be unique across outstanding requests from all DSML clients running on the computer, and possibly across reboots (given SMTP latencies)? (This is as opposed to an LDAP operation, where the message ID must only be unique across the requests outstanding for a single LDAP session.)
How is the message ID determined for something analogous to an LDIF file, where the contents of the operations might be determined long before the operations are performed? If the message ID were embedded in the file when the file was generated, it wouldn't be possible to assert the message ID to be unique. If the message ID were not embedded in the file (e.g., if an optional attribute or filled in by whatever process reads the DSML file), how could a response file be generated that would still allow the client to match responses to the requests in the original request file? (One option: The message ID scheme could be used as a supplement to rather than a replacement for the positional request/response pairings.)
How are you proposing that this affect the rest of the strawman proposal?
-J
-----Original Message-----
From: John McGarvey [mailto:mcgarvey@us.ibm.com]
Sent: Saturday, July 28, 2001 10:13 PM
To: Jeff Parham
Cc: dsml@lists.oasis-open.org
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