Bill de hÓra wrote:
James M Snell wrote:
Thoughts?
The mot straightforward way (imo) to deal with encoded fragments is to
use two attributes, ie @type and @enc. So defining a new extension
attribute would work for me.
See my comments below on the type identification.
Here's another challenge... what about Text constructs like summary that
only allow html, text and xhtml values for their type attribute. It
would apear that we cannot embed an EncryptedData element in Text
constructs. I dunno, is this a problem? Outside <content />, I really
don't think we should be encouraging folks to encrypt individual
metadata elements as that could get rather silly.
So perhaps we should limit XML encryption to
a) The entire feed
b) individual entries and
c) the content of content elements. (examples 2, 4 and 5 in my
original note).
I'm not sure you need to deal with signalling the type of a fully
encrypted document in your case 5; if it's not possible to signal the
type via xmlenc I'd claim it's a spec bug there, not here.
You know... it really would help if I *re-read* the relevant specs
before opening my mouth ;-) The EncryptedData element already has
attributes for specifying the original type of the encrypted data. Now
I just feel silly.
Example 1:
<feed>
<entry>
<content type="text">This is some text</content>
</entry>
</feed>
Becomes
<feed>
<entry>
<content type="application/xenc+xml">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content
MimeType="text/plain">...</EncryptedData>
</content>
</entry>
</feed>
Example 2:
<feed>
<entry>
<content type="html"><p>This is some HTML</p></content>
</entry>
</feed>
Becomes
<feed>
<entry>
<content type="application/xenc+xml">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content";
MimeType="text/html">...</EncryptedData>
</content>
</entry>
</feed>
(note to self: read the damn spec next time ;-) )
cheers
Bill
- James
