RE: [dss-x] Visual Document Signatures

["Uri Resnitzky" <Uri@arx.com>]

Stefan,

I think you are making some very good points:
- Names and IDs should be better specified
- File format specific stuff should be separated
- UTC should be used instead of GMT

Lets discuss in today's call the strategy to update the document and
keep track of changes and revisions.

Thanks,

- Uri

> -----Original Message-----
> From: Stefan Drees [mailto:stefan@drees.name] 
> Sent: Monday, 06 August, 2007 11:59
> To: Uri Resnitzky; dss-x@lists.oasis-open.org
> Cc: stefan@drees.name
> Subject: Re: [dss-x] Visual Document Signatures
> 
> Dear Uri,
> > "Uri Resnitzky" <Uri@arx.com> wrote on 20070805T194629+0200:
> > ...
> > Please find attached ARX's contribution towards a profile 
> for visual 
> > document signatures.
> > The attached document is by no means complete or fully 
> specified - it 
> > should be viewed as a basis for further discussions.
> > Please start by reading section 3 which describes some of the key 
> > aspects of the proposed profile as well as motivations and 
> use cases.
> 
> I consider this a very good start for us into the analysis of 
> what should be included in such a profile and what should be 
> better separated into different profiles.
> 
> Some adhoc feedback (probably a bit superficial) from me:
> 
> <document date='20070805' 
> id='oasis-dss-profiles-visual-document-signatures-wd-01.pdf'>
> <location>
> <input>4.1.1.5 Optional Input 
> &lt;ReturnPDFTailOnly&gt</input> <feedback date='20070806' 
> origin='sdrees' id='DomainSpecific'>If the Profile targets at 
> PDF, ODF and OOXML, it MAY be a better choice to embed client 
> format specific information elements into an extra (optional) 
> container. In a then second level, the profile may have 
> elements bearing specialized names of importance to only one 
> specific processing hierarchie/chain. This may result in 
> parsing efficiency, where the file-format-specific parsers 
> are only used inside "the processing of" the 
> "Here_MAY_be_file_format_specific_settings_inside"-Container
> </feedback>
> </location>
> 
> 
> <location>
> <input>4.1.1.6 Optional Input 
> &lt;GraphicImageName&gt;</input> <feedback  date='20070806' 
> origin='sdrees' id='NameOrID_01'> I expect some discussions 
> here, clarifying two problems (as far as I can see) 1. Is it 
> a Name or is it an ID (unique name [plus conventions]) and if 
> it is a kind of ID (I assume this from context): who has 
> enough information to know and/or select from such a set of IDs.
> This is not necessarily the task of the profile, but it may 
> render using the profile problematic if not taking it into 
> account. I picture this as the usual problem, when many 
> end-users have to choose among signatures, addresses and the 
> like while using applications, that try to display "stuff 
> partially but nicely" ...
> </feedback>
> </location>
> 
> 
> <location>
> <input>4.1.1.7 Optional Input &lt;SignatureFieldName&gt;</input>
> <feedback  date='20070806' origin='sdrees' id='NameOrID_02'> 
> This is only listed separately for taking into account, that 
> a "funny picture" 
> as someone put this may be of complete different meaning as 
> compared to a CMS or XML Signature.
> Besides this, please see also feedback with regard to
> "4.1.1.6 Optional Input &lt;GraphicImageName&gt;".
> </feedback>
> </location>
> 
> <location>
> <input>4.1.1.9 Optional Input &lt;GMTOffset&gt;</input> 
> <feedback  date='20070806' origin='sdrees' 
> id='ServerTimeOffsetUTC'> At a minimum I would suggest the 
> nowadays correct UTC (Universal Time Coordinated) in exchange 
> with GMT (Greenwich Mean Time). 
> What I would personally tend to name it, would be more along 
> the lines of &lt;ServerTimeUTCOffset&gt;, to emphasize the 
> intended impact in the processing.
> </feedback>
> </location>
> </document>
> 
> 
> ALl the best,
> Stefan Drees.
>