Hi,
I am currently implementing RFC 3195 RAW in an ultra-slim way (yes, I've
taken up the task of ending this "simple tcp syslog" discussion). I am
not sure yet if the project works out, but I was at least able to send
messages to SDSC with very view code on my side.
However, I came across a question which I can not find the answer to in
the RFC. In the RAW description (3.), it says:
---
All BEEP
messages in the RAW profile are specified as having a MIME Content-
Type [6] of application/octet-stream.
---
In the first sample below, it specifies:
---
.
.
.
I: ANS 1 0 . 0 61 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
---
If you look at this, it looks like the payload of this BEEP frame is
\r\n [CRLF]
<29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
To me, this initally looked like while there is no content-type
specified, the message still contains the (then empty) MIME header.
Which is then terminated by CRLF. While working with SDSC, I found that
it does NOT expect the CRLF to be present (in fact, it fails, if it is).
I then looked through 3195, 3080 and 2045 and nowhere found mentioned
that this CRLF must be present. RFC 3080 says in 2.2:
---
A message is structured according to the rules of MIME. Accordingly,
each message may begin with "entity-headers" (c.f., MIME's Section 3
[1]). If none, or only some, of the "entity-headers" are present:
o the default "Content-Type" is "application/octet-stream"; and,
o the default "Content-Transfer-Encoding" is "binary".
---
Other than that, 3080 specified payload just to be *OCTET. From the
description, however, I think that the CRLF in syslog raw payload is NOT
necessary.
Even 3195 does not say anything specifically about this CRLF, it is just
in the samples. Of couse, I may be overlooking the obvious ... So I
thought I simply ask. Could someone clarify? Mtr, do you have any
advise?
Thanks,
Rainer
