[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] cooked messages max size
Hi MC,
On Wed, 18 May 2005 SFBZH@aol.com wrote:
> Sorry for that but I have to insist. Could anyone please have have a look
> on that issue?
>
> I really need to know how IETF interpret RFC 3195:
> Are Syslog Cooked messages allowed to be longer than 1024 characters?
> I have read RFC 3195 and 3164 several times and I have not found any
> undeniable specification about that.
If you've looked and can't figure it out, then it must not be properly
specified. The Working Group would like to hear your opnion on a
resolution.
The IETF process works this way:
- An INFORMATIONAL document (like RFC 3164) can be used to tell how things
have been done in the past. It's really not a STANDARD and shouldn't be
treated as one. The most important thing about RFC 3164 was its
Security Considerations part that showed most of the flaws in a "fire &
forget" system.
- There are three stages of a document that is on the STANDARDS TRACK.
These are shown in RFC 2026.
http://www.ietf.org/rfc/rfc2026.txt
- RFC 3195 is currently in the Proposed Standard state. It's been out
for a while and people are implementing it and coming up with concerns
about it.
- The problems that are seen in implementations and deployments of an
RFC can be addressed by revising the document. This will "obsolete"
the prior RFC. If the protocol is widely deployed and everyone seems
happy with it, then it will be moved to Draft Standard.
- Once someone has been out for a while and everyone is happy with it
and the documents are very thorough then it can be moved to Internet
Standard state.
The Working Group will need to revise RFC 3195 based upon two things:
- People who are developing code and deploying it need to speak up and let
us know what works, and what doesn't work and how it can be resolved.
- The acceptance of syslog-protocol will force some changes as a reliable
transport for syslog should have mechanisms to convey the newly defined
fields in a proper manner.
Essentially, if you write your implementation of RFC 3195 to convey
messages larger than 1024 bytes, and you convince a majority of others to
do the same, then the revision of RFC 3195 will follow what you've done.
This mailing list is open for people to discuss implementation problems
and how things should be resolved. :)
Thanks,
Chris
>
> Best Regards
>
> MC
>
> >
> My question is based on RFC 3195 & 3164.
> In those RFC, it is clearly specified that BSD & RAW messages can't be
> longer than 1024 characters. Otherwise, the syslog servers & relays
> ignore the end of the message. What about cooked messages?
>
> The part of the cooked message which could get long is the CDATA of the
> entry element. In RFC 3195, we can read this:
> The character data for the element is the unstructured syslog event
> message being logged. If the original device delivers the message
> for the first time via the COOKED profile, it may have any structure
> inside the CDATA. However, for maximum compatibility, the device
> SHOULD format the CDATA of the message in accordance with Sections
> 4.2.1 through 4.2.3 of [1].
> [1] is RFC 3164.
> First, sections 4.2.1 to 4.2.3 in RFC 3164 don't exist. I assume that
> RFC 3195 refers to sections 4.1.1 to 4.1.3 of RFC 3164. (Since many
> sites have copied RFC 3195, it will probably be difficult to catch up
> that error.)
>
> The limit of BSD messages size is not defined in those sections. It is
> defined just before it, between the 4.1 title and the 4.1.1 title. The
> result is that, technicaly, no size limit seems to be defined for cooked
> messages.
> I suppose that, for backward compatibility reasons, cooked messages have
> to be shorter than 1024 characters. Could anyone confirm this, please?
>
> MC
> <
> _______________________________________________
> Syslog-sec mailing list
> Syslog-sec@www.employees.org
> http://www.employees.org/mailman/listinfo/syslog-sec
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec