RE: Completing the tables SRR MEP description.

Hi Noah,

Firstly, as I hit the send button on my previous response I realised that I
should have prefaced it with something like "think aloud" which was inspired
by your message rather than being a direct response to it.

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 15 April 2002 15:18
> To: Williams, Stuart
> Cc: Williams, Stuart; 'xml-dist-app@w3.org'
> Subject: RE: Completing the tables SRR MEP description.
> 
> 
> Thanks.  I'm also curious about your reaction to my specific suggestion. I

> am nervous about requiring even the simplest clients to handle the 
> overlap.

What I was trying to do was agree with you that the possibility of deadlock
was real, but disagree addressing this necessarily leads to significant
complexity.

I guess you made two specific suggestions

a) Don't address it now... stick with a binding that doesn't allow the
overlap. The overlapping case can be addressed later.

b) The likely future solution being the defn of a header (SOAP or HTTP?)
that signals the requesting nodes willingness to engage in overlapping
request/response.

I would be ok. if we made the first choice. In my previous response I did
point out that (IMO) it introduces a conformance requirement that a
responding node not begin the sending of a response before it has completely
received a request. I believe that that is a direct implication of making
that choice.

On the nature of some future solution that involves the defn of a new
header... I feel a bit nervous. The problem of overlapping request/response
is not a SOAP specific problem. It's a generic problem at least for HTTP, I
believe it is possible in BEEP and would be possible in a binding to TCP
(say SOAP/DIME(for framing)/TCP). In the HTTP case, I think that *if* HTTP
addresses the 'generic' problem then SOAP should be leveraging that
solution, rather than re-inventing it. 

On yesterday's TBTF call I asked Henrik how the HTTP spec. handles this. On
the call he said that HTTP requires that HTTP clients using POST MUST be
capable of send and receiving concurrently and that HTTP requires this. I
have tried to find this in RFC 2616 and so far I have failed. I'd appreciate
a pointer to (spec.) chapter and verse on this.

I expect that Henrik is correct and that HTTP does indeed require that HTTP
clients that use POST (and I guess PUT as well) be capable of handling
overlapping request/responses, then its a real possibility that the start of
a response may show up before a request has been fully transmitted (likewise
with BEEP).

In discussion on the call, I agreed to explore the possibility of collapsing
the MEP description into Requesting, "Requesting+Receiving", Success and
Fail states at the requesting node and Receiving, Receving+Responding,
Success and Fail at the responding node. Also to look at how this would
effect the HTTP binding. I've committed to having this available for
mid-week (COB Thursday UK at the lastest, earlier if possible) for
consideration at TBTF call on Friday.

>  That seems like a big mistake.

If Henrik is correct it is already a requirement imposed by the HTTP spec.

> So:  why not make the default "no overlap".  
> If you want streaming, then as a client, you must signal 
> that with a header.  The header triggers a feature with the semantic that 
> the request originator MUST pull responses while sending the request, and 
> the responder MAY stream the response?  I think that's very SOAP-like, 
> it's the best of both worlds, and the only downside is the need for the 
> client to include the header.  Later, we could always name a separate 
> binding that mandates streaming in all cases.

We could go that way... I'm not fundementally opposed to it. I think the
problem is more generic to the underlying protocol, and any effective
underlying protocol needs to have a solution for this type of problem within
its spec, otherwise it itself admits the possibility of dead-lock which
would be bad. *IF* HTTP already addresses this issue, I don't think that we
should be re-solving it in SOAP. OTOH, if HTTP itself mandates not behaviour
that avoids the potential for deadlock then we can use the kind of mechanism
you suggest (assuming an SOAP header) to condition SOAP's use of the
underlying protocol.

> I strongly feel that the default binding should not put such a tricky 
> burden on the clients.  Even though HTTP in prinicple always allows it, in

> practice it's rare to have a large POST overlapped with a large response. 
> I bet that many stacks are buggy in this area or don't even try.  Deadlock

> is a very ugly failure mode.  I think we should keep the base case simple,

> especially since we have an easy way to the extension.  I'm neutral as to 
> whether we should publish the streaming feature on day 1 and as normative.


I'm not against doing as you suggest. However, I haven't yet concluded that
we can't write a simply articulated specification for an MEP (and the HTTP
binding) that allows for overlapping case and draws appropriate attention to
requirements that HTTP clients using HTTP POST MUST/SHOULD be capable of
concurrently sending and receiving.

>  Many thanks.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------

Regards

Stuart

Received on Tuesday, 16 April 2002 05:56:23 UTC