- From: Todd.Glassey@Meridianus.Com <Todd.Glassey@www.meridianus.com>
- Date: Thu, 24 Jun 1999 07:54:33 -0700
- To: "Bugbee, Larry" <Larry.Bugbee@PSS.Boeing.com>, <'reagle@w3.org'>
- Cc: <w3c-ietf-xmldsig@w3.org>
Hi all, ----- Original Message ----- From: Bugbee, Larry <Larry.Bugbee@PSS.Boeing.com> To: <'reagle@w3.org'> Cc: <w3c-ietf-xmldsig@w3.org> Sent: Wednesday, June 23, 1999 5:20 PM Subject: Signed-XML and White Space? > Hi Joseph, > > When you sign something you may or may not care about white space (extra spaces, CR/LF, etc.). For example, you might not care about white space if it is a paragraphs of simple text and your assertion is that those words are yours. Line breaks are unimportant giving the renderer choices. So, signing words and their breaks is all that is necessary. When you sign something you care very much about the whitespace. What you are singing may in these cases be displayed as an "empty character" represented in UTF-8 or ASCII, but it is in fact part of a binary stream of data. The hashing that produces the event representitive image processes the white space as though it was what it is - an ASCII space or null character - so just because it displays through the presentation engine as a "space" it isn't an instance of "no data". > > If, however, the content were a purchase order, spacing is extremely important lest the right numbers appear in the wrong columns. Here we should sign all the white space and have it preserved upon rendering. > > How should we go about this? Do we care? We care very much about this, but it is a key issue of what and how we treat the objects we are trying to prove identity for, which brings us back to my favorite subject of late, persistent objects... and how we manage signatures and the like for digital instrument processing. > > Food for thought... Yes lets think about this!!! > > Larry As I have said to a number of people privately, the answer may be simply to use a preprocessor pass on the XML source stream to enforece the construct of the persistant objects. > > Larry, since you opened this can of worms anyway, I ask the question "What in the general XML use model provides a guarenteed forms traversa and supports the consistancy of the objects represented in the XML data stream?". The answer is that the browser that displays the file does this since it processes the file in a top down manner, i.e. as a sequential serial stream. This is an important concept since it addresses the First Person use of a document. No broswer - No document context ------------------------------------- The problem is that as soon as we lose the browser, there is nothing in the language itself to enforce forms traversal or any other type of flow control with regard to the processing of the documents. Nor will there ever likely be. XML as a derivitive of SGML suffers a number of the issues with top-down presentation engines that rely on the data stream as part of their control paradigm. This is an impirtant issue to contend with since the traversal on a text document can be proven easily, but is linked to a facility to the presentation engine, per say. Why? ------ Now the reason this happened is IMHO simply the way we read, it is a 'paper based' thing, but the reality is that if we don't use a presentation engine to 'display' the document, but rather use it in the sense of an enabling chit, then there is some pretty serious 'grey area' here as to the provable content and intent behind the flow of the document itself. So then persistence in objects and the abilty to under a demonsterable policy framework, install this sense of what comes first, etc etc. Paper != Digital ---------------- By comparison, these are use model issues that have not plagued paper based processes becuase the paper document install their own flow. It's something as a culture we agreed upon some time ago and this has just not happened for the digital arena yet. The Fix? --------- As to the fix itself, my feeling is that the issue of the persistance of objects is not something that can easily be addressed in a "Passive" display engine without some active content management. To this end it seems like XML should have a way of being both preprocessed and compiled and that there *must* be a way of piping the output of the preprocessor into the display framework or event processing framework, securely. (Note the use of the term 'must' here!). Right now all we do is interpret it. In the preprocessing instance #1 we should maybe try the "persistant object" proposal I have sent to many of you (Anyone else who wants a copy send me email to todd.glassey@meridianus.com, or if there is enough interest, I will put it on the BERT standards page which our GMTsw arm operates - http://www.gmtsw.com/ietf/bert ) or in instance #2, there is another proposal that also dovetails into the process. For the sense of legal documents, there may be a need in the #2 instance of stand-alone document to specify a framework for their interpretation, and this should also allow for their "compiling" that is being combined with the presentation engine primatives so that the module can become an EXE and stand on its own two feet (without an external display engine...) Our Resolve -------------- Pending approval from the group, our folks could hopefully have the pre-processor models ready for a topical persentation for the Oslo meeting so they could at least be discussed, and while I won't be there personally, Michael McNeil will be - so we should be able to hold a reasonable discussion. As to the Binary Document Harness that supports an XML carrier, I have adraft that should fly on it in the next 3 weeks. Anyone interested in working with us on this should contact me immediately. Todd Glassey
Received on Thursday, 24 June 1999 10:55:26 UTC