Alex, thanks for the suggestion. However, a very similar scheme was already proposed in -protocol-03. Please see section 6 in
http://www.syslog.cc/ietf/drafts/draft-ietf-syslog-protocol-03.txt It has been removed from the spec because it was concensus - after month-long discussions - that this should not be in the spec. For similar reasons, a similar approach was removed from Anton's I-D. While I personally still feel it would be worth having it in the draft, I do not like the idea to re-spawn the long, long discussion we had on this topic. I think it would be time to get -protocol close to finish and re-itereating that discussion will probably cause us another very long delay. I also think the arguments are the same that already were exchanged. For some past discussion, please review these threads: http://www.mail-archive.com/syslog-sec@www.employees.org/msg00056.html http://www.syslog.cc/ietf/autoarc/msg01109.html http://www.syslog.cc/ietf/autoarc/msg01294.html http://www.syslog.cc/ietf/autoarc/msg01299.html To get a better view of our current concensus, I would like to ask all those that would like to see a fragmentation scheme back in the syslog protocol to speak up now. Thanks, Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Alexander Clemm (alex) > Sent: Wednesday, May 11, 2005 3:14 AM > To: syslog-sec@employees.org > Subject: Syslog message fragmentation (was: RE: [Syslog-sec] > Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt)) > > Hi, > > one more topic, concerning message fragmentation. I believe Anton > Okmianski may also have brought this up in the past. > > While it is possible to address multi-part messages as part of > additional SD elements, possibly defined in an add-on > specification, it > appears it would make sense to incorporate this capability into the > syslog protocol itself, specifically since truncating is defined also. > This concerns the ability to "break up" a message into multiple > fragments, example part 1 of 3, part 2 of 3, and part 3 of 3, if the > message would otherwise be too long. Such a fragmentation COULD be > carried out by an sender, including interim systems (relays). > > The following is a sketch what this would look like. Clearly, if it > were decided to incorporate, more detailed specification is required. > In essence, fragmentation would require an additional field, > possibly a > standard SD element. The field would consist of the following > components, delimited per a to be determined convention: > - A message identifier. (This is not the same as the MSG-ID, as it > would refer to a particular message instance, not to a message type.) > - Which part of the message this is (first, second, third, and so on) > - How many parts there are in total. > > Subsequent messages that are different parts would all reiterate the > header of the message, probably also the structured data (this aspect > could be discussed). It would be the message part itself > that would be > subjected to fragmentation. > > As it is not permitted to have multiple instances of the same SD > Element, recursive multiple fragmentations would curently be > prohibited. > This would mean it is NOT permitted to have a part 2 of 2 of > a part 1 of > 3. If this constraint shall be maintained, it should also be specified > that IF fragmentation should occur, that the fragments should be small > for each of the fragments not to include 480 octets including > header and > SD data. > > Anyway, if there is interest in this the details can be worked out for > sure. Again, I believe this would be a very useful feature to > incorporate. Comments? > > Regards > --- Alex > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Alexander > Clemm (alex) > Sent: Monday, May 02, 2005 8:47 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] Syslog protocol > draft(draft-ietf-syslog-protocol-11.txt) > > [...] > > Concerning message length: would it make sense to allow for a means by > which messages could be fragmented, as an option in addition to > truncating? This could be addressed by having standard > structured data > elements that specify a message as part 1 of 2, for example. > Of course, > with regards to relays it may imply that messages may need to > be altered > by relays accordingly. > > [...] > _______________________________________________ > 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
