RE: [Syslog-sec] cooked messages max size

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Hi Robert, 

I agree on the need to support more than 1024 characters. This has been
discussed in this WG in length. However, I do NOT think that
RFC3195/COOKED currently supports more than 1024 characters inside the
message.

I am also not aware of any implementation of RFC3195/COOKED that
supports this size. The only implementations of 3195 I know of are
listed at:

http://www.syslog.cc/ietf/rfcs/3195.html

I would appreciate if you could let me know other implementation of it,
especially if it supports messages > 1K.

Rainer

> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org 
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Robert Horn
> Sent: Thursday, May 19, 2005 9:10 PM
> To: Marshall Glen <glen.f.marshall
> Cc: syslog-sec@willers.employees.org
> Subject: RE: [Syslog-sec] cooked messages max size
> 
> 
> Also, a refinement of the RFC 3881can be found at:
> 
> ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf
> 
> This takes the general framework of RFC 3881 and further specifies
> requirements for how particular events are to be encoded for medical
> devices.
> 
> One of the interesting things learned in the early work with 
> this is that
> describing events in XML consumes quite a few bytes.  Really 
> simple events
> fit under 1024 bytes, but it does not take much complexity to 
> push past
> that limit. A much more realistic limit to impose is a 64KB 
> limit.   The
> commonplace event that  "PACS archive sent study X about patient Y to
> workstation A to prestage it for physician Z based on current 
> appointment
> schedules" chews up a surprisingly large message if you include full
> details about the study, machines, and times.  Since these 
> messages are
> defined by multiple schema with namespaces (to manage 
> inheritance properly)
> fully qualified XML tags can become quite large all on their own.
> 
> The ability of the COOKED transport to indicate the schema is 
> also useful
> for the receiving servers so that they can route and parse much more
> effectively.
> 
> R Horn
> 
> _______________________________________________
> 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