RE: One-way messaging in SOAP 1.2

How do you feel about Jacek's proposal to use "PUT"?  My point is just that
putting the indication of one-way vs. request response in the envelope
would require envelope parsing to make the determination.  You seem to be
saying that putting it anywhere in the payload is contrary to http....so,
would using PUT be an appropriate way to signal to the server?  Surely that
represents a degree of client control that is traditional in http (vs.,
e.g. GET, in which the client is signalling a request for data from the
server)?

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





                                                                                                                                      
                      "Henrik Frystyk                                                                                                 
                      Nielsen"                 To:      "Williams, Stuart" <skw@hplb.hpl.hp.com>, Noah Mendelsohn/CAM/Lotus@Lotus,    
                      <henrikn@microso         "Christopher Ferris <chris.ferris"                                                     
                      ft.com>                  cc:      "marc.hadley" <marc.hadley@sun.com>, "xml-dist-app" <xml-dist-app@w3.org>     
                      Sent by:                 Subject: RE: One-way messaging in SOAP 1.2                                             
                      xml-dist-app-req                                                                                                
                      uest@w3.org                                                                                                     
                                                                                                                                      
                                                                                                                                      
                      01/23/02 03:29                                                                                                  
                      PM                                                                                                              
                                                                                                                                      
                                                                                                                                      





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 Thursday, 24 January 2002 21:41:11 UTC