FW: Comments on uber-MEP

Forwarding this thread to public dist-app. The exposure to a small
amount of unapproved minutes is 
mitigated by the much larger technical discussion intended for public
access.
 
Thx, Mike


________________________________

	From: w3c-xml-protocol-wg-request@w3.org
[mailto:w3c-xml-protocol-wg-request@w3.org] On Behalf Of ext David
Orchard
	Sent: Monday, November 28, 2005 1:58 PM
	To: w3c-xml-protocol-wg@w3.org
	Subject: Comments on uber-MEP
	
	

	I see from the minutes, 

	<Yves> noah: not really happy with the no-MEP option. the way a
binding know how to send a message is a normative thing in the spec.
Saying it's in the rec but we won't use it would be an issue 

	<Yves> noah: there may be more protocols than HTTP that supports
natively request/response 

	<Yves> and the soap level MEP allow to abstract that 

	<Yves> concern witht he uber-MEP is that Request-reponse MEP is
already there, adding another MEP might introduce an incompatibility 

	<Yves> also adding too much possibilities may undermine its
usefulness 

	<Yves> for example if a request -response is expected and no
response comes, would that trigger a binding level fault? 

	<scribe> ACTION: Noah to send email describing position on uber
MEP/no MEP/new MEP due 30 Nov [recorded in
http://www.w3.org/2005/11/16-xmlprotocol-minutes.html#action02] 

	 

	 

	The uber-MEP is a protocol level MEP (and abstract from any
particular protocol) and thus any protocol that supports
request-response is handled.  There will be another MEP anyways, so it's
whether to have a SOAP only MEP or have a more general MEP as the one
new MEP.  The issue about request-response dealing with no response is
already a problem, because right now you can use WS-A with req-response
but put a non-anon value in replyTo.  This doesn't cause a binding fault
currently because WS-A overrides this constraint.

	 

	Dave

Received on Wednesday, 30 November 2005 01:10:11 UTC