octet-based processing model

Hi all,

I clearly failed to understand the octet-based processing model concept
when reading the encryption spec and this list, and I now see that there
were a few requests for comments. My (verbose) comment is that I disagree
with it.

Far from simplifying things, it adds (for me, obviously) unnecessary
confusion and complexity to what is otherwise a functional and
straightforward spec.

If we simply remove all reference to character encoding, streams of
data, the encoding of parent documents, etc. (other than the necessary
translation of XML content prior to data encipherment), the spec becomes
much clearer, and toolkits lose the bonds that prevent them from
implementng encryption how they want, using DOM, SAX, characters, etc.

I implemented the spec (obviously without reading it properly) and it
works elegantly and efficiently with a node-based processing model,
and it integrates seamlessly with signatures. I get pains even thinking
about tinkering with streams of bytes. That does not seem (to me) to be
a realistic *REQUIRED* model. If we leave the spec free of such
assumptions and requirements, many more implementations are possible:

1. octet-based system that messes around with characters
2. DOM-based system that works with nodes
3. SAX-based system that streams events
4. system that uses native class mappings of the schema
5. integral part of an XML parser chain
6...

I do not believe that 1 is the dominant case (I would suggest that 2,
4 and 5 are), and I do not believe that we should restrict ourselves
to it.

It seems to me that removing *any* assumption of model from the spec
reduces its size and complexity, but increases its power and has (to my
inflamed eyes) no shortcomings.

I'm probably missing the obvious; could someone please clarify?

Thanks, merlin


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Thursday, 23 August 2001 14:24:21 UTC