- From: Frystyk <frystyk@w3.org>
- Date: Fri, 20 Apr 2001 16:11:43 -0700
- To: <dick@8760.com>, <soapbuilders@yahoogroups.com>
- Cc: <xml-dist-app@w3.org>
>The SOAP 1.1 spec says the following about SOAPAction: > >"6.1.1 The SOAPAction HTTP Header Field >The SOAPAction HTTP request header field can be used to >indicate the intent of the SOAP HTTP request. The value is a >URI identifying the intent. SOAP places no restrictions on the >format or specificity of the URI or that it is resolvable. An >HTTP client MUST use this header field when issuing a SOAP >HTTP Request." > >Can you explain why you feel ebXML must use an absolute URI >for SOAPAction, given the above description of SOAPAction >within the SOAP spec. Certainly, the reason is that the consequence of the ebXML spec defining the relative URI "ebxml" is that this implies that all URIs ending in "ebxml" identify the same thing (the contents being an ebXML message). Examples are http://www.w3.org/ebxml http://www.ms.com/ebxml http://www.sun.com/ebxml Because the relative URI "ebxml" has to be expanded against the request-URI of the HTTP request. I don't think the guys owning the namespaces above are likely to agree with this :) This is not really a SOAP problem but a URI problem in that it breaks the URI model [1][2]. The fix is for ebXML to use a single globally unique URI which means that the value in 99.99999% of the case will have to be absolute because the request-URI will have nothing in common with the ebXML URI. This will also ensure that other parties won't start to use URIs ending in "ebxml" over which you have no control and that doesn't mean what the ebXML specs defines it to mean. In other words, using a globally unique URI ensures that ebXML won't run into name conflict problems later on. Hope this helps, Henrik [1] http://www.w3.org/DesignIssues/Model.html [2] http://www.normos.org/ietf/rfc/rfc2396.txt
Received on Friday, 20 April 2001 19:14:27 UTC