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
