RE: Irvine Minutes and ost-FTF syntax proposal

A couple comments:

> -----Original Message-----
> From: reagle [mailto:reagle@w3.org]
> Sent: Tuesday, September 07, 1999 5:15 PM
> To: jboyer
> Cc: reagle; w3c-ietf-xmldsig
> Subject: RE: Irvine Minutes and ost-FTF syntax proposal
> 
> 
> At 12:06 99/09/07 -0700, John Boyer wrote:
>  >_
>  >>Consensus. The reference from SignedInfo will just be a 
> URI. This can then
>  >>  point to a manifest or package which can use Xlink/Xptr/Xpath as
>  >>appropriate.     This means you don't have to worry about 
> Xptr in the core
>  >>signature syntax.
>  >Perhaps I misunderstood what that meant.  Did you just mean 
> that we could
>  >punt the problem of having to make up a syntax for 
> exclusion?  Please
>  >clarify.
> 
> For the core syntax yes.

I agree we need to clarify the types of references in the spec (on the todo 
list).

>  ><John>
>  >Actually, this wasn't my interpretation of what was said at 
> the FTF nor is
>  >it reflected in the post-FTF Solo syntax.  The signedinfo contains a
>  >signedobjectreference, which includes a transformations 
> element, which
>  >includes the exclusion functionality (which we are 
> proposing would use some
>  >form of Xptr).  Also, this is why I've been under the 
> impression that this
>  >would be part of core syntax.
>  ></John>
> 
> This was not my understanding, but you are right the latest 
> Solo reflects
> your position. I was rather please we would be able to push 
> XPtr into the
> manifest spec (since I figure XPtr is part of the manifest 
> reference) and it
> would make the core syntax all the easier to implement 
> quickly. Perhaps I
> was mistaken.

My recollection from Irvine was that given the desire to sign a variety of 
things, not all of which were XML, we'd leave the exclusion (or extraction) 
transform in for the time being until we were sure we could handle all the 
cases without it.

>  ><John>
>  >Actually, that's a great question!  I was all in favor of 
> this approach
>  >myself until Milt Anderson burst our bubble (and rightly 
> so!) by pointing
>  >out that it may be necessary to do transforms such as 
> base64 decoding
> before
>  >we apply the Xptr.  Kudos Milt!
>  ></John>
> 
> Well, we need to get the order of that stuff right 
> regardless, should be
> specified in the spec.
>  >Peter Norman's actual suggestion was actually more 
> sophisticated.  He
>  >proposed having a special element to mark regions to be 
> signed by each
>  >signature.  The marker elements would be dropped out of the 
> signature, but
>  >they bracket the regions that should be signed.  However, 
> since this is a
>  >positive (inclusive) method, rather than an exclusive one, 
> it still loses
>  >the document closure battle. (In partial answer to the 
> question of what do
>  >the Xptrs do that the proposed idea doesn't do).
> 
> Understood.
> 

I'm also trying to sort out situations where one might need to switch between 
XML encodings (as to/from binary XML).

Dave