Re:9991216 Minutes

>    3. When Object is used for data (as specified in the Type attribute),
>       do not include start/end tages in hash and auto-decode per any
>       Encoding attribute. 

Great!

<snip/>
>       Reagle: If our concern is referring to manifests, just use an ID
>       in the Manifest element and refer to that! Concerns about moving
>       an encoded object from within an object to elsewhere would be more
>       tricky. Boyer: wrote an email to Himes on how to do this, will
>       send to list.
>       RESULT: no change, but clarify text that references can ref to
>       Manifest directly.

Sorry, I'm having trouble keeping track of our current state (how we are keeping
track of what is dereferenced, etc.)  If we are allowing location to be changed
for core behavior (are we?), and we are decoding (base64) content for the hash,
why is it tricky?  I believe John's solution involves retrieving the external
document, reconstructing the internal configuration, then starting the signature
process.  Not as clean as signing the unencoded data and allowing location (e.g.
IDREF or URL) to float.

>    6. Pull SignatureProperties up to the level of Object.
>       Eastlake: removes extra level of nesting.
>       Reagle: likes to keep an Object as the bucket to place non-core
>       syntax and semantics.
>       Fox: wants a strong reason for us to make a change.

Better design should be a strong enough reason for any changes we make at this
point.  I understand that we need to start finalizing things, and I understand
that there has probably been code investment, but I don't think we should freeze
it too early at the cost of capability, simplicity, or lucidity for the rest of
the world.

Thanks,
Rich

Received on Thursday, 16 December 1999 16:49:28 UTC