W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2005

FW: Comments on uber-MEP

From: <michael.mahan@nokia.com>
Date: Tue, 29 Nov 2005 17:00:01 -0800
Message-ID: <A5F46F7A688C084782E8C52B7636861301C15B2D@sdebe101.NOE.Nokia.com>
To: <xml-dist-app@w3.org>

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
Thx, Mike


	From: w3c-xml-protocol-wg-request@w3.org
[mailto:w3c-xml-protocol-wg-request@w3.org] On Behalf Of ext David
	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

	<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



	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.



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC