Last Call XMLP comments to XMLE: expires Friday Dec 14th

The following presents the XML Protocol Working Group response to the call
responses to canonicalization [1] WD.  In addition, XMLP chair was verbally
asked to respond to XMLE, as asked for some time ago in [2].

XMLE specific:
Comments were sent July[3], and are still not addressed.  The comments are
around the usage scenarios of SOAP with XMLE, and the
processing model under validation and transformation.  Because XMLE provides
a schema, it presumably must be used by an XML Schema validator.  But there
is no treatment for how a document author of the unencrypted content or
schema should use the XMLE schema - especially given that XMLE content will
be inside SOAP elements.

In general, the comments are not SOAP specific.  The same questions arise
when retrieving a document with XMLE content whether it be SOAP or foo
encoded.  We suggest that the XMLE group should provide documentation that
describes the expected processing and validation model for documents
containing XMLE content.  While section 4 of [1] describes detailed element
processing, perhaps a new section describing message/document processing
would be useful, eg. "4.4 Complete message processing model".  I'm not sure
whether it should be normative or non-normative, though I lean to
non-normative.  Perhaps another option - though I'm not in favour of it -
would be to have a separate document published by XMLE on the topic.

If it is true that encyrption of portions of SOAP messgaes are a primary
justification for XMLE then it seems fairly important to have at least
described the overall processing model and how it works for SOAP messages.
We suggest that treatment of an enrypted and/or signed SOAP header would be
sufficient usage scenario that would satisfy other non-soap applications.
should include a SOAP example under XMLE processing.

This would certainly help for groups that have publicly stated intensions of
use SOAP and XMLE, such as OASIS SAML.

Exc-C14N specific:
The Exc-C14N, in conjunction with XML-C14N, deals with canonicalization
independent of insignificant transformations permitted by XML 1.0
and Namespaces in XML, but does not deal with insignificant
transformations permitted by XML Schema.  This will limit its applicability
to those XMLP-based messages which will be XML Schema cognizant.

For example, the C14N specs do not deal with insignificant
transformations permitted by various XML Schema built-in datatypes
such as use of {true,false,0,1} for boolean datatype, or case-insensitivity
to "e" in scientific notation.

The C14N specs also deal with addition of default attribute (value), but not
with the default value of element content specified in XML Schema.

Minor comment on definition of terms:
If "an orphan node is a node whose parent element node is not in the
document subset"
then how can there be an "output parent of an orphan node" if this is
defined to be
"the output parent of an orphan node .. is the nearest
   ancestor element of the orphan node that is in the document subset"?

Dave Orchard

Received on Wednesday, 12 December 2001 17:00:57 UTC