Re: [Passwordsafe-devel] Format Tests

[dk <dk...@gm...>]

Wolfgang,

Honest - I am really not intending to cause any "unnecessary obstacles".  I
apologise if my posts appear so - that was not the intent - probably my use
of the English Language.  I value other people's contributions and ideas.
The more the better.

Nothing I have said in these posts is fixed - they are only my current
opinion and could easily change.  Rony is the final arbiter and there is no
guarantee that he will pick my view, your view or anyone else's; that is why
I have asked for a "draft specification" for the next and future formats so
they can be discussed more widely.

I have put my answers in the body of your message below prefixed by ">>>".

Regards,

David


-----Original Message-----
From: pas...@li...
[mailto:pas...@li...] On Behalf Of
Wolfgang Keller
Sent: 21 May 2007 20:24
To: pas...@li...
Subject: Re: [Passwordsafe-devel] Format Tests

David,

from some of your recent posts I have been wondering whether you are causing
unnecessary obstacles, but then again I'm not sure. Let me say that if you
don't like the idea of cooperation, just say a word and I'm backing off. - I
regard my contributions here as offers to the benefit of the PWS file
format. I'm not doing this to please the PWS project or its people but for
the sake of a community, whether big or small, who might be using this file
format under various applications and possibly various purposes. - It is my
believe that all users and all PWS applications will benefit from an open
and effective file format regulation, providing the means for as little
loss/friction as possible when files are cross-used among several PWS
applications or various historical software versions.

>>> I agree in open discussion and sharing of views to the betterment of
PWS.

It is my believe, hence, that the format definition should be a) as simple
as possible, b) as tolerant as possible. In this light I'ld comment on some
of your recent points:

i)  (Simplicity I) no sequence prescriptions in any field arrays! The format
definition should make it explicit that both header field list and record
field list must be fully apprehended in random type sequence of its fields.
Any ordering prescriptions might cause problems in applications and is a
superfluous source of errors. There is no algorithmic necessity for any
ordering (with the exception of the list terminating field 0xff).

>>> I agree in most cases except the Version, which I think should come
first, and the EOF, which must come last.  Whilst there is no "algorithmic
necessity for any ordering", from a coding perspective, it is much nicer if
you know the header version before you start processing the header fields
than half way through.

ii)  (Simplicity II) no complex field structures where possible; so I
support suggestion to create 2 fields for "Last operator" and "Last host
(computer)"

>>> At least we can agree on this! ;-)

iii) (Tolerance I) the most simple and effective rule here is that a PWS
application should preserve unknown fields when saving a file, regardless of
their place and value, i.e. no two-class support depending on type ranges or
the record/header distiction. Anything else I regard as over-protective
(protect what exactly?) and again forseeably - but hopefully not
deliberately - causing problems.

>>> Again I agree and have coded this in the latest revision of PWS for both
unknown saving header and record fields (the latter being stored encrypted
in memory whereas the header fields are considered OK as clear text).  One
point here, you say your current application is Format V3.01 compliant and
yet the record time fields are 8 bytes long when the format specifies only
4.  It may well be the case, as I have explained, that it works OK today
with the release version of PWS but it may not in future and isn't
compliant.  That is not to say that a future version (V3.02?) might specify
that this field can be either 4 or 8 bytes long - it just doesn't in V3.01.

iv)  (Tolerance II) as a compensation for openness there must exist a
regulation to devide usage of field types. The simple 0x7f boundary does the
job as already described and secures a wide range of fields for the world of
PWS only. I personally have seen a second boundary at 0x3f; above it and
below 0x7f could be a range for "approved PWS applications" 
(well, I don't like the word "clones" any more because mutual feature copy
is already in full swing). Specific type values would be given out to these
application once they need them. This has the advantage that these approved
applications share a protected zone and could refer to the "rest of the
world" as "using above 0x7f types". I walk from the assumption here that 64
field types will provide for many more decades of development of the
(native) PWS program. - (The second boundary is an add-on and the system
also works without it.)

>>> I am not sure I understand this paragraph.  The 0x7f was a 'suggestion'
for the boundary in both the Header and individual records.  I don't mind if
it is 0x3f or 0xcf or any other 'nice' boundary.  Personally, I would not
like it less than 0x3f, although I can't think of what other fields we could
want in the header or records - but I am sure someone can!

That's how I've seen it,
- Wolfgang

dk wrote:
> Wolfgang,
>
> I have replied to your Support Request as I had some difficulties with 
> the time fields in the records and header.
>
> However, on further tracing, I see that the order in which you write 
> the header records seems to be in the inverse of their type value.  
> There is nothing in the "FormatVn.txt" file to say this is wrong.  
> However, I would like the format changed to mandate that the version 
> number (record type
> 0x00) is *always* the first field in the header.
>
> Regards,
>
> David
>
>
>
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the
FREE version of DB2 express and take control of your XML. No limits. Just
data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Passwordsafe-devel mailing list
Pas...@li...
https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel