At 01:19 AM 10/11/00 -0400, Alex Brown wrote:
>Chris Lonvick wrote:
>
>> but I'd like to see it articulated in the ID. I'll also accept any
>> discussion of this on the list if anyone sees any problems with this.
>
>I think it's clear enough, but I'll add a few words to that effect.
Everything needs to be very clear as this will be the document that the
protocol developers will reference when they are developing their code.
>> - We discussed the length field and I think that we all have found that
>> current versions will only accept 1024-bytes of the message. That is
>> defined in the current syslog ID but it may be that this can be changed
>> with this ID. I would still like to see a maximum length described in
>> this ID for this new-style message format.
>
>The discussion here doesn't deal with the small length limit, which
>should be evident in any UDP protocol; again, I can add some words.
You could pad the entire length of the traditional message up to 1024
bytes and then add your designators|values.
>> - Would it be acceptable to use some of the unused or reserved values of
>> the current syslog priority values to differentiate between this "new"
>> format and the "traditional" format?
>
>I don't see the point. This is intended to provide some limited
>authentication for the whole log stream, not just for certain
>facilities/priorities, etc.
The highest value of the priority as it goes across the wire is <191>.
Would it be a good idea to _and_ this with a constant such as <200>
so that there would be no confusion whether it was an old-style or
new-style message? In that way, we would have the following:
Fac Svr Old_style_value New_style_value
0 0 <0> <200>
16 4 <20> <220>
184 7 <191> <391>
Alternatively, the angle brackets could be replaced.
[0] or
(20) or
:191:
Discussion from the group would be good here. :-)
>
>> - Is this going to be limited to md5 or are other hash algorithms going
>> to be accepted?
>
>Again, that's up to the implementor. This is just an indication of a
>general method.
I think that there needs to be at least one defined algorithm along with
its identifier. Alternatively, you could propose defined fields where the
value is the MD5 hash exclusively. Otherwise, each implementor will
define their own hash and we won't have any interoperability.
Thanks,
Chris
