OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: XML Content namespacing



In today's teleconf, I promised to propose a solution to the namespacing issues dealing
with the two children elements of the <xmlContent> element, namely <keyXMLContent>
and <embeddedXMLContent> (as there was lots of discussion on this point).

The problem arises since there maybe XML namespaces used in the <embeddedXMLContent>
that you wish to also use in the <keyXMLContent>, or, in some cases, the <embeddedXMLContent>
is being encrypted and you don't expose the XML namespaces.

Part of the problem is that we have two child elements to deal with, and one (possibly more)
namespace(s) to support.

The reason for having two child elements was to support the use case of the xml content
being encrypted, but still having some (non critical) elements exposed in clear text.
However, there is a way we in which we can use one (and only one) element for xml content that
can support this use case.

Consider the below example, where the xml payload is all expressed within the <xmlContent>
element (assume there is no <keyXMLContent>and <embeddedXMLContent> children elements.
The payload is a CAP message that is encrypted (ie all the stuff between the <EncryptedData>
elements) and three CAP elements at the beginning of the payload that you want to be open and
readable.

<ed:xmlContent>
  <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1">
<identifier>KAR0-0306112239-SW</identifier>  
<source>SW</source>
<scope>Public</scope>
  </alert>
  <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element
    xmlns="http://www.w3.org/2001/04/xmlenc#">
       ----encrypted CAP elements are here--
  </EncryptedData>
<ed:xmlContent>

In this example, we also show the use of XML namespace defaulting. That is, the CAP 
and XML Encryption namespace prefixes are not used - although you can - and are default
to the enclosing elements.

You could also express the above with explicit XML namespaces as:

<ed:xmlContent>
  <cap:alert xmlns:cap= "urn:oasis:names:tc:emergency:cap:1.1">
<cap:identifier>KAR0-0306112239-SW</cap:identifier>  
<cap:source>SW</cap:source>
<cap:scope>Public</cap:scope>
  </cap:alert>
  <ec:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element
    xmlns:ec="http://www.w3.org/2001/04/xmlenc#">
       ----encrypted CAP elements are here--
  </ec:EncryptedData>
<ed:xmlContent>

So, my proposal would be to simplify the specification by using one element <xmlContent>
for all XML payloads. You can use default and/or explicit XML Namespace prefixes.
And since you can include any XML, you can expose any encrypted XML in the same element.

Cheers...  Renato Iannella
National ICT Australia (NICTA)


--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]