On 11/21/02 3:11 AM, "Albert Mietus" <[EMAIL PROTECTED]> wrote:
Here are my opinions:
> ----------------
>
> ** A Signature Block contains a signature. of itself
> There is a (at least) 1 space between the signature and
> the hashes before it.
> Q: Should the hash/signature be calculated including or
> excluding those spaces
>
Excluding.
> ** All fields in Signature an Certificate Block should be
> separated by space
> Adv: It should be exactly 1 space, except before a (terminating)signature;
> where 2 spaces are recommended
>
I'm willing to make it be exactly one space, but I prefer to keep it so that
it's at least one space and whitespace is ignored.
> ** Same as above (twice) for Certblocks
>
The same.
> ** The rfc defines the Fragment Length (field G) of the CertificateBlock
> as base64 coded. This seams wrong, as it is a normal, printable number.
> (The rfc says that base-64 is only used for binary values, generally)
>
This is a tradeoff. If it's base64, then you get 4:3 expansion. If it's in
hex, you get 2:1 expansion. Given that syslog packets are of a fixed,
relatively small size, this can be important.
>
> ** The rfc is not uniform in "counting" spaces. Sometimes a terminating space
> is part of a field, and the length of the field is "extended" with 1.
> Sometimes, the space is situated between 2 field. And the
> length(s) count the actual (non-space) content.
> Often, it is not clearly specified.
>
I'll take a look, but I'll repeat the above with a comment. There's a
principle of "be conservative in what you generate and liberal in what you
accept." I'd say that best implementer's practice is to only ever emit one
terminating space anywhere. If a space is part of a field, then don't emit
another one. Similarly, best practice is that you shouldn't ever barf
because someone put in an extra space.
> Adv: Always define the space as "between", for Payload, Certificate en
> Signature Blocks (not for "normal", rfc3164) messages.
> Adv: use "MUST be separated by spaces" ..."RECOMMENDED is to use 1
> space, (except as written above)". "receivers/validators MUST
> accept any number of spaces.
>
Okay.
> ** The TAG is defined to be ending ('MUST')with a _colon_.
> This wrong, as rfc3164 defines it can end with a _space_
> Adv Rewrite: it terminates with any not alfanum char.
>
Hmmm. Let me look.
> ** I think, it should be "better" to show a signature Block
> in an example, not "normal" messages
>
> ** Make a note about NOT terminating base-64 coded fields with a
> newline. This is normally done in base-64. A short remark can
> simplify the implementator's job
>
Uh, yeah. There shouldn't be newlines anywhere, should there be? Why would
anyone think there should be?
> ** In 3.5 and in 4.2.c (ii) & (ii), is specified PRI should be "XXX"
> Rfc3164 does not allow this!
> (and so it can't be used here. as all messages should be
> processable by rfc3164-compliant syslog(d)'s.
We're rewriting part of this anyway. Let me see if the new thing meets with
your approval.
