RE: What is the purpose of the NamespaceSupported element?

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Subject: What is the purpose of the NamespaceSupported element?

 Comments inline. 

The entire description of the NamespaceSupported element currently consists of:

'The NamespaceSupported element identifies any namespace extensions supported by the messaging service implementation. Examples are Security Services Markup Language[S2ML] and Transaction Authority Markup Language[XAML]. For example, support for the S2ML namespace would be defined as follows:

<NamespaceSupported location = "http://www.s2ml.org/s2ml.xsd" version = "0.8">http://www.s2ml.org/s2ml</NamespaceSupported>'

I find the above description rather obscure. It is not clear to me how an implementation would actually makes use of this information. The Messaging Service spec does not refer to any such concept defined in the CPA. 

One use of namespace supported in the CPP is to have a way to indicate that XMLDsig is employed. That allows  implementations to know whether they can accept the security packaging. More information will eventually be needed here,  as has been indicated in the list of known items that are to be worked on. For example, alternative XPaths in signatures have been suggested as possible elements to be included.

Likewise, because adding namespaces is one way that XML infosets are extended, interoperability can be expected to involve support for namespaces that are used, either in the header or in the payload. Is this obscure? We can certainly add some more text to clarify that the point of a CPP is to advertise capabilities with the view of promoting interoperability.

The message spec does, or did, have an "any" element for extensions at one point. Has that disappeared?

 

The example in Appendix A shows:

<tp:NamespaceSupported tp:location = "http://ebxml.org/project_teams/transport/messageService.xsd" tp:version="0.98b">http://www.ebxml.org/namespaces/messageService</tp:NamespaceSupported>

<tp:NamespaceSupported tp:location = "http://ebxml.org/project_teams/transport/xmldsig-core-schema.xsd" tp:version="1.0">http://www.w3.org/2000/09/xmldsig</tp:NamespaceSupported>

Is the namespace http://ebxml.org/project_teams/transport/messageService.xsd explicitly identified to show that ebXML Messaging Service is used? 

Yes. It need not be when CPPAs are used.

   Does it hurt if the above namespace is not explicitly identified?  

Possibly, possibly not. There may be versioning usages or even specific variants that are used within a collaboration community. The issue is how much to default out, I take it, not whether the info. is useful in advertising capabilities that pertain to interoperability.

 Similarly, must the namespace http://ebxml.org/project_teams/transport/xmldsig-core-schema.xsd be explicitly identified if XMLDSIG is used? 

That is how we indicate that XMLDsig is being used in a CPP.

  Isn't it already known that the Messaging Service calls for the use of XMLDSIG for sigining purposes?  

Yes. Perhaps an example omitting XMLDsig and using SMIME encryption would have been more useful. In addition, when a namespace URI for XML encryption emerges, we can add that to the list if it is to be used even though it is not a part of MS
G spec now. Finally, the constituent specs are to be modular and possibly independent. What is required by MSG is not necessarily required by CPPA. So what can be a default because it is part of MSG would be OK if we agree to make all features of MSG the default for CPPA. That has not been proposed as yet, and it may tend to conflict with the intent to have each spec remain modular and independent.