Top-level directory is not good (the same reason as before, links in file
system). But I have changed my opinion, I agree; how about changing
"protect" rule (because it has already become 90% redundant -- don't ask
me how I get these figures... ;-)):
protect <template>
protect <template> <authentication>
protect <template> <authentication> <protection>
<authentication> is something like "basic", "pubkey", "Kerberos", etc.
<protection> is something like "NONE", "MIC-ONLY", "ENCRYPT".
And there would also be two additional fields in rule file:
default_authentication <authentication>
default_protection <protection>
Which are used if <authentication> and/or <protection> is not provided
in "protect" rule, or if there is no "protect" but there is an existing
ALC file.
> > * A reply from a protected server starts with a status line:
> >
> > HTTP/1.0 202 Privacy enhanced reply follows
> Why define a new code? IMHO, all this information should be in headers,
> not on the status line. You even already defined headers for this, so
> this is really just duplicate information. Does it really serve any
> purpose?
Well now that I think about it, it doesn't serve any purpose. Ok, it's
going bye-bye.
> Oh, BTW, TimBL had suggested using WWW-foo: for the new headers we define
> to avoid collisions. Of course, any headers you are using from existing
> specs or proposals are fine.
Ok, so they will be:
Both:
WWW-Body-MIC: These could be only one MIC-Info: with
WWW-Header-MIC: multiple subfields. How about it?
Request:
Authorization: This is already in use, and was in HTTP spec
when I started on this, so no "WWW-".
Reply:
WWW-Authenticate:
WWW-Protection-Template:
Key-Info: These
DEK-Info: two are like in PEM.
-- Ari --