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
