Next in thread → Next in month →

RE: What is the purpose of the NamespaceSupported element?

From
Dale Moberg <>
Date
2001-08-20T20:53:17+00:00
ID
Thread
RE: What is the purpose of the NamespaceSupported element?
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.
Next in thread → Next in month →