RE: One-way messaging in SOAP 1.2

A problem with the proposed solution of introducing a new HTTP header
field is that the 202 Accepted status code which is the status code in
question is an HTTP response and responses are by definition determined
by the server and not by the client.

There is no mechanism to change that in HTTP and introducing an HTTP
header field with this sort of semantics would be a significant change
to HTTP. I don't think we want to go down this route - it is a *very*
slippery slope.

Henrik 

>> -----Original Message-----
>> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
>> Sent: 17 January 2002 18:55
>> To: Christopher Ferris <chris.ferris
>> Cc: marc.hadley; skw; xml-dist-app
>> Subject: Re: One-way messaging in SOAP 1.2
>> 
>> 
>
><snip/>
>> Those are options.  Why not do it this way:
>> 
>> * In the binding framework, state that:  "Binding 
>specifications that 
>> support more than one MEP MUST specify the means by which the 
>> recipient of a message can determine the MEP being used.
>
>+1
>
>
>
>> * In the HTTP binding state:  "This binding specification 
>provides the
>> following means for distinguishing use of the one way MEP 
>> from requests
>> send using the Request/Response MEP:
>> - A SOAPMessagePattern: HTTP header is defined with the 
>> values 'OneWay' or
>> 'RequestResponse' (perhaps these should be URI's for extensibility?)
>
>Yes... in fact we are naming our MEPs with URI's and this 
>would be a good
>use for such URI names. I feel somewhat reticient about 
>defining another
>HTTP header... but if thats what we have to do... its more 
>extensible in the
>long run than using different HTTP method (say PUT... if 
>that's viable for
>use with SOAP).
>
>> - The MEP MAY be implicit in the URI used to deliver the message
>
>Not keen on this one as it overloads (conflates?) 
>identification the next
>recipient with of an immediate destination (of a hop) with 
>denotation of the
>MEP in use.
>
>> - In situations where more than one MEP is used in conjunction with a
>> single destination address, the SOAPMessagePattern HTTP 
>header MUST be
>used
>> to identify the MEP.
>> We could instead go with your suggestion that HTTP depend on 
>a header in
>> the envelope.  I'm nervous that you don't really want to 
>parse the XML
>> before making the determination.  I'm also a bit nervous 
>about more HTTP
>> headers, but on balance I think we need something outside the 
>> envelope.
>
>If we're going to mark the difference (which I think we should 
>if a binding
>supports multiple MEPs) then yes, I think it needs to be outside the
>envelope too.
>
>> In any case, I really do think the framework should make it the
>> responsibility of the binding to convey the MEP in use (explicitly or
>> implictly -- for example, if a binding only supports one MEP, 
>> then there is no need to send anything with the message).  
>What do you 
>> think about this approach?
>
>+1
>
>> 
>> ------------------------------------------------------------------
>> Noah Mendelsohn                              Voice: 1-617-693-4036
>> IBM Corporation                                Fax: 1-617-693-8676
>> One Rogers Street
>> Cambridge, MA 02142
>> ------------------------------------------------------------------
>> 
>
>regards
>
>
>Stuart
>
>

Received on Wednesday, 23 January 2002 15:30:16 UTC