Re: XMLP/XMLE Use cases and processing models

On Wednesday 13 February 2002 18:33, David Orchard wrote:
> In this note I will focus on one particular issue, context information
> about an XML Document and its contents.  I'd like to point out that the
> TAG is currently examining the issue of dispatch based upon content-type,
> namespace names, and root element names [1]. 

As an aside, I see people use the term "dispatch" a lot, and not always 
consistently. Anyone have a handy definition/principles/treatment of the 
concept and its implementations?

> we need some more tweaking on the wording.  I do feel comfortable saying
> that registeration of a content type for an xml vocabulary that may be
> embedded within another and is intended to be dispatched on - like xenc
> and xslt - is likely to be an outcome.
> 1. XML Encryption registers a content-type, perhaps
> application/xmlencrypted.

I have an action item to register a 'application/xenc+xml' type. I need to 
register it, and maybe after I read those 5 RFCs [a] I'll understand some 
of these issues better! :)

[a] http://www.iana.org/cgi-bin/mediatypes.pl

> 2. XML Encryption say wording to the effect that a document containing a
> vocabulary that also contains encrypted content where the decryption is
> required to make the instance conform with the vocabulary namespace name,
> MUST provide some metadata to indicate decryption is required.  Changed
> namespace names, content-type (this is my step #7 in algorithm following)
> , SOAP mustUnderstand intermediaries (step #6 is algorithm following) are
> valid examples of this.

Such a MUST is counter to the requirements, and such constraints can be 
rather meaningless if they don't have a test of implementation or 
interoperability. We aren't writing the spec of what generic XML processors 
MUST do, nor what SOAP applications MUST do.

> 3. The XMLE group entertain the definition of algorithms for dispatch
> based upon content-type, namespace names, and/or other metadata.  It may
> be that this is an XMLE/XMLP liason issue or a web services architecture
> wg issue though.

This is an open issue. The www-xenc-xmlp-tf@w3.org list has no official 
sanction or appointments and outside from some xenc folk and yourself, not 
a lot of participation. I'm happy to keep learning about the issue, but if 
it needs more attention it should get escalated somewhere. But I understand 
it *is* being discussed at TAG.

> I find your option #4 to be interesting and worthwhile pursuing and very
> appropriate for SOAP, though I suggest a different approach that allows
> decryption to occur without the use of a decrypting actor.  The solution
> of creating metadata is exactly the right path to go down.  We could try
> to merge the content-type for messages concept with the content-type for
> header blocks.  The use of a content-type for the whole message solves
> this problem for messages outside the SOAP context, so I think we could
> apply this to headers.  What I think we might need is a "content-type"
> for the block content.

I'd defer to others if this satisfies there application requirements, and 
to the XP WG if they want to add such an attribute. My uninformed 
understanding of SOAP is that it makes use of content-type in the binding 
(HTTP headers) but nowhere else?

> Taking a look at the header more closely, my proposal is that the header
> is labeled as a content-type application/xmlencryption, ie <header><po:po
> xmlns:po="..." soap:content-type="application/xmlencryption"
>
> ><xenc:encrypteddata/></po:po></header>.  In this fragment, the po
> > namespace

Is 'po' short for a Purchasing Order example/scenario?

> There is a 5th option that I propose to add to your list of options.
> 5. The namespace name is left as is, and a Content-type of
> application/xmlencryption is used for messages and/or blocks.  A receiver
> then dispatches to an decrypting service for decryption.  Presumably this
> would know which encrypted elements to decrypt, and as well how to
> dispatch to the next node.

I'm sure I missed it, but I'm not sure what the content type attribute 
improves over what Takeshi proposed with:
  env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"

> I see a rough algorithm of dispatch relating to XMLE:
>
> 1. If the entire message is encrypted and sent then the root element will
> be changed to the encryption element.  The first receiving node can do
> dispatch based upon the root element or the encryption namespace name.

By message, you mean the SOAP-ENV:Body. Yes, I'm ok with this whatever 
mechanism (envelope, must-understand, content-type) mechanism SOAP uses.

> 2. If a portion of a message is encrypted, and the message cannot be
> interpreted without decryption first, then a content-type of
> application/xmlencryption must be used.  The namespace name can be left
> as the unencrypted namespace name.  The receiving node dispatches based
> upon the content-type.  Your second example fits here.  This technique
> has been used for compression as well, with content type application/gzip
> used.

Ok, so you're trying to use the content-type in addition to the namespace 
to provide more information about what to do.  I think what you've done is create one 
more bit of syntax so you have one more level of description for a 
processing model (a grand total of two), but it isn't generic. For example, 
what happens if its an XHTML document with a bit of xenc and xslt? Who gets 
to take over the content-type then? My understanding of Tim's position on 
this is that applications should not be dueling and fighting over the root 
element or content type. I think I agree. I'd rather have a document be a 
broken xhtml file (with a chunk of xenc in it) where xhtml defines what to 
do than the jostling for control. If need be, XHTML (or any other app) can 
ignore or try to invoke external namespaces. Or it could be specified via 
some nesting (e.g., SOAP headers) or an external specification (e.g., 
xmldsig transforms or some other XML processing pipeline.) But all of this 
is subject to debate now and not solely XENC's issue. (And I'm not up on 
all the debate either, so I'd defer to the experts in the TAG, WSAG or 
whatever and look forward to commenting on any proposal.)

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Friday, 15 February 2002 18:38:49 UTC