John, the issue is the simplex nature of syslog. With syslog (other than with almost all other protocols), you send a message and need to *hope* that the recipient can receive it. There is also no negotiation phase. So you need to send it blindly. For example, if you send an IHE 2K message, but the receiver does just support 1K, you will loose 1K without knowing it. As such, it is vital to know at least a "safe size" that you can use and know that it can be processed (if it makes it to the recipient). We selected 480 octets because that fits into an unfragmented UDP packet in any case. I know that's too few for IHE, but for network management - an important use case for syslog - this is very often sufficient. This is the reason why a simplex protocol like syslog (send it and forget it ;)) should provide some guidance about lower limits. Keep in mind that there is NO upper limit - this is done in the transport mappings and the implementations. So if you need 32K for IHE, that is perfectly well (-transport-UDP, I think, suppport 64K - but you know the practical limits).
Does this clarify? Rainer > -----Original Message----- > From: Moehrke, John (GE Healthcare) [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 30, 2005 6:13 PM > To: Rainer Gerhards; Darren Reed > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] #2, max message size > > Shouldn't the MTU be defined by the binding to the transport? > I fail to > see why the protocol, unbound to a transport, needs to have a limit. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > > Sent: Wednesday, November 30, 2005 11:01 AM > > To: Darren Reed > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Syslog] #2, max message size > > > > Darren, > > > > I violently object your argument and leave it up to the > rest of the WG > > what should be done. I respect your argument, but I do not like to > > re-iterate this forever. > > > > One time we have discussed this was in October 2004: > > > > http://www.syslog.cc/ietf/autoarc/msg01289.html > > > > If you browse the archive, you will find several other > ocasions where > > this was discussed. > > > > What's your actual recommendation? Do not say anything and > > leave it the > > implementor to guess what is OK? After all, its the implementor's > > problem if the message can not be transmitted. Or do you prefer to > > define an API where the lower layer tells the upper layer what > > capabilities it has? Maybe MTU discovery? Or an app-level > ack? I think > > all of these options have already been discussed during the > > past years. > > What is now in is a (fragile) consensus, but if only you do > > not like it, > > I think we should go ahead and leave an unhappy Darren > > behind. If only I > > insist on it, we can also go ahead and leave an unhappy > Rainer behind. > > But we need to go ahead! > > > > Rainer > > > > > -----Original Message----- > > > From: Darren Reed [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, November 30, 2005 4:49 PM > > > To: Rainer Gerhards > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: [Syslog] #2, max message size > > > > > > > Darren, > > > > > > > > > The only place a message size limit should be specified is in > > > > > a transport > > > > > mapping. If it's in -15 then it should be removed. Limits > > > > > of all sizes > > > > > and types do nothing but contribute to aging of a protocol. > > > > > > > > -protocol-15 is a compromise after a very long > > discussion. It says: > > > > > > > > ----- > > > > A receiver MUST be able to accept messages up to and > > > including 480 > > > > octets in length. For interoperability reasons, all receiver > > > > implementations SHOULD be able to accept messages up to > > > and including > > > > 2,048 octets in length. > > > > > > > > If a receiver receives a message with a length larger > > than 2,048 > > > > octets, or larger than it supports, the receiver MAY > > discard the > > > > message or truncate the payload. > > > > ----- > > > > > > > > I think this text is useful. It keeps the door open for any size > > > > messages while still allowing it to be restricted by > the transport > > > > mappings and individual implementations (e.g. on > low-end embedded > > > > devices). It cautions implementors against being too > > > verbose but also > > > > sets a lower limit that each implementation can assume to > > > be received. > > > > > > > > I think we should continue to use this text. Do you agree? > > > > > > No. That text doesn't belong in this draft. > > > > > > Darren > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
