W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2001

RE: [soapbuilders] question re: namespace hierarchies

From: Dick Brooks <dick@8760.com>
Date: Sat, 21 Apr 2001 12:33:02 -0500
To: <frystyk@microsoft.com>, <soapbuilders@yahoogroups.com>
Cc: <xml-dist-app@w3.org>
Message-ID: <NDBBIOBLMLCDOHCHIKMGGEKKFLAA.dick@8760.com>
Henrik,

> 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).

Actually, I think consistent use of the ebXML moniker will help with
interoperability.
The use of "shared, consistent knowledge" is a common practice that has
proven
successful, for example:
- TCP/IP port 25 is associated with the SMTP protocol across domains
- TCP/IP port 80 is associated with the HTTP protocol across domains

If the relative "ebXML" moniker has consistent meaning at each URL, kind of
like index.html,
then this would be a good thing, IMO.

This discussion of ebXML's planned use of a relative path URI for SOAPAction
has given
me a reason to consider what others in the SOAP community are doing with
SOAPAction.

Are others planning to use only absolute URI's for SOAPAction?

Are you planning to use relative URI's?

When should one use an absolute/relative URI for SOAPAction?

How are current SOAPBuilders using the SOAPAction during "inbound"
processing of a SOAP
message?

What are SOAPBuilders on the client "outbound" side expecting SOAPAction to
do
for them?

Is SOAPAction only useful on the server side?

Will client side implementers be forced to set SOAPAction according to the
desires
of their own network/firewall admin in order to allow/deny passthru on a
firewall?
If so then the client side may have to dictate the value of SOAPAction.

Thanks in advance for your help.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Frystyk
> Sent: Friday, April 20, 2001 6:12 PM
> To: Dick Brooks; soapbuilders@yahoogroups.com
> Cc: xml-dist-app@w3.org
> Subject: RE: [soapbuilders] question re: namespace hierarchies
>
>
>
> >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 Saturday, 21 April 2001 13:33:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:00 GMT