Re: [dss] Discussion on outstanding issues for the core.

[Juan Carlos Cruellas Ibarz <cruellas@ac.upc.es>]

At 00:53 11/05/2004 -0700, Trevor Perrin wrote:
>At 11:30 PM 5/10/2004 -0400, ed.shallow@rogers.com wrote:
>>Yeah, looks pretty good. See minor tweaks inter-mixed.
>>
>>----- Original Message -----
>>From: "Trevor Perrin" <trevp@trevp.net>
>> >
>> > Okay, I think I got it.  These are the changes I'll make, unless someone
>> > objects:
>> > [...]
>> > If an error occurs verifying multiple
>> > signatures, the first error will be returned.
>>We should invite implementations to explore the InvalidDetail unbounded
>>element of ProcessingDetails if they wish to return error information on 2nd
>>and subsequent signatures.
>
>Do you mean "profiles" instead of "implementations"?
>
I think that what is appearing here is that at the very moment we will face
the production of a profile for multiple singatures with high degree of
details
we will have to expand hte capabilities of these elements. Could it make sense
to generate a profile for that that could be shared by other profiles?

Juan Carlos.

>
>> >The server should first check any <ds:Reference/@URI> that may be present
>> >against each Input Document's RefURI, and if a
>> > match is not found, then try to resolve barename XPointers against the
>> > signature's Input Document or Signature Object.
>>It was for this reason that I wanted to collapse SignatureObject,
>>SignaturePtr, and WhichDocument into simpler constructs within a tweaked
>>InputDocument structure. Given what we are doing, it improves readability.
>>I'll defer to the will of the majority though.
>
>That's what I was alluding to Friday, that having a combination of 
>old-style Input Documents URI matching & new-style server-processing of 
>XPointers is kinda messy.  But I'm not sure we've got the energy or 
>patience for a redesign, and as Nick points out profiles can simplify 
>processing if they want.  So I'll just go ahead with these changes, for now.
>
>Trevor
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.
>