Re: [GNU Crypto] RFC: New keystore format

[Raif S. Naffah]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On Sat, 19 Jul 2003 09:58 am, Casey Marshall wrote:
> On Sat, Jul 19, 2003 at 06:45:00AM +1000, Raif S. Naffah wrote:
> > On Fri, 18 Jul 2003 01:08 pm, Casey Marshall wrote:
> > > On Fri, Jul 18, 2003 at 05:34:34AM +1000, Raif S. Naffah wrote:
> > > > On Thu, 17 Jul 2003 07:57 am, Casey Marshall wrote:
> > > > > On Wed, Jul 16, 2003 at 11:26:47PM +1000, Raif S. Naffah
> > > > > wrote:
> > > >...
> > > [URIs ...]
> > >
> > > We could perhaps fudge it, since the the most common value of
> > > this field would probably be a file: URI or a simple path with
> > > '/' as the file separator. This could be handled with the URL and
> > > File classes. Or our implementation could just support
> > > well-formed file: URLs but still leave the specification open.
> >
> > are you saying use "file:" as the default protocol if none is
> > specified in the uri string?  if yes then agreed.  in the
> > implementation though,
>
> Or, only support URLs in our initial implementation (URLs are a
> subset of URIs, right?).

yes, and they include the protocol scheme.  see 
<http://www.w3.org/Addressing/>.


> > > > > > * MAGIC0, MAGIC1, and MAGIC2 are 4-octets...
> > > > >
> > > > > I'm not sure of the need of different magic values for
> > > > > different keyrings.
> > > >
> > > > the keyring files contain different types of data; the distinct
> > > > MAGIC helps (a) instantiate the appropriate scanner, and (b)
> > > > decide which types are illegal if/when they are included.
> > >
> > > I've just been approaching this from a very generic standpoint,
> > > and that a valid file could have any valid combination of
> > > elements which any parser will be able to handle. When it comes
> > > to writing data, however, the normal behavior
> > >
> > > Again it just feels sort of dirty and overengineered.
> >
> > if certain files shall contain certain type(s), and only those
> > types, of data, then using a different MAGIC value for those files
> > is an explicit rendition of the specification.  on the other hand,
> > if a file can contain different types, then we dont need one per
> > file type.
> >
> > what is it?
>
> My intention was to allow any valid file to contain any valid
> objects, but at out application layer we enforce the separation.
>
> (Admittedly, this may be the wrong way to do it, but I didn't want to
> bring content restrictions into the actual file format, making it of
> better generic use)

if we stick to the keyring_params_file concept i dont see how not to 
separate them and still keep both the specification and implemntation 
simple.


cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/GUsg+e1AKnsTRiERA7UdAKDinDgdReC6Jk3uFa1xq/6/cQzrUACfYSOy
Wz/b0KkYe3Su8P646XDAgIE=
=YCjl
-----END PGP SIGNATURE-----