The draft text does not set a limit on maximum size. It sets a minimum support boundary, which simplifies the basic interop. Is it a problem?
The reason for the minimum size to be specified in message protocol and not the transport was to sets the basic expectation for minimum support from transport mappings. For example, if I have a system that fires messages to a sender sub-system and the sender-subsystem can be configured to use a number of transport binding... What is the minimum message I am guaranteed that all receivers will support regardless of the transport used? This information can be critical when you design some important messages. Of course, specifying a minimum required support in each transport mapping is also appropriate. In fact, syslog-transport-udp sets two separate minimums: for IPv4 and IPv6. If we did not specify a minimum in syslog-protocol, one can infer the minimum based on the least common denominator of transport protocol used. That's fair. But I just don't see a harm in what was done in the current draft (after very long discussions I might add). I can only a see a very hypothetical scenario where some future transport protocol has MTU smaller than the what IPv4 and IPv6 uses. In this case a minimum requirement may be problematic. How much lower than 480 octets can it go with a ~100-octet syslog header? Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Wednesday, November 30, 2005 12:01 PM > 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 > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
