OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: RE: [dss-x] Groups - Visible Signature Profile - Working Draft V6 (oasis-dssx-1.0-profiles-visiblesig-wd6.doc) uploaded

Hello Andreas,

My responses below.


-----Original Message-----
From: kuehne@trustable.de [mailto:kuehne@trustable.de] 
Sent: Wednesday, April 15, 2009 6:36 PM
To: Ezer Farhi; kuehne@trustable.de; dss-x@lists.oasis-open.org
Subject: Re: RE: [dss-x] Groups - Visible Signature Profile - Working
Draft V6 (oasis-dssx-1.0-profiles-visiblesig-wd6.doc) uploaded

Hi Ezer,
hope you got a nice holiday.

> - line 360 : DocumentRestrictionLevel is _not_ optional, but dtmo it
> MUST be.
> <Ezer - this parameter is relevant only for the PDF-Certify operation
> and is not relevant for other types of documents. 
Yes, that's  why I vote for the optional attribute ! Currently it's the
only elemnt not optional in the given schema snippet.
<Ezer - Got it. I will correct it.

> - DocumentRestrictionLevel : Could you please explain valid values and
> their meaning. Anyway, I would prefer urn instead of an integer.
> <Ezer - Any explanation will tie the values to PDF, which I was trying
> to avoid.
Hmm, my colleague was lost when he came across this element. This
shouldn't happen to future readers of the profile. Maybe you can give a
hint where to look for possible values ...
<Ezer - I fully agree. I will specify the values in the profile and
point to the adobe specifications>
> - line 537 : DateTime is defined, but never used. All date / time
> values are generated by the server.
> <Ezer - So your suggestion is to remove it? What about cases when the
> client would like to supply only the time format?
Oh, I see ! I got this element completely wrong. It's not intended to
format a transmitted date but the visible representation. OK !
<Ezer - and also the value of this element is defined by the server.

> - line 395 : Does DocumentID tries to introduce a mechanism to sign
> multiple documents with one call ? Dtmo a single call should deliver a
> single signaure. We got this decussion some years ago ...
> <Ezer - I was under the impression that the core allows signing
> documents in one call, having each document has its own signature. If
> not, what is the aim of sending several documents?
Please can someone correct me if I'm wrong, but I got the belief that
one request gives one signature. A hint may be that the mechanism you
introduce here is missing for the core informations.
<Ezer - This issue needs further discussion. If the core will not allow
several signatures per request, then this element will be removed.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]