[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] RFC: New keystore format
From: |
Raif S. Naffah |
Subject: |
Re: [GNU Crypto] RFC: New keystore format |
Date: |
Sat, 19 Jul 2003 23:43:59 +1000 |
User-agent: |
KMail/1.5.1 |
-----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-----
- Re: [GNU Crypto] RFC: New keystore format, (continued)
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/13
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/13
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/14
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/17
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/17
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/18
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/18
- Re: [GNU Crypto] RFC: New keystore format,
Raif S. Naffah <=