Hi WG, I have edited syslog-protocol so that we are now at -protocol-03. I have submitted it to the IETF this morning, but as the draft editor is probably very swamped with the number of new IDs prior to the Seoul meeting, I have agreed with Chris on publishing the not yet officially relased ID on my site. I do so in the hope that this will allow us to work out some of the issues before Seoul (and eventually identify new ones).
It was a rather complete edit, I have placed a full change log on my comment's page at http://www.syslog.cc/ietf/drafts/comments-draft-ietf-syslog-protocol-03. html This page also links to the "unofficial" -protocol-03 version. This version addresses many of the issues we discussed the past days. Rather than individual replies, I'd appreciate if you could have a look at the new ID. For those without time to access the web, my edit summary is as follows: - general text-cleanup. Abstract and Intro modified. I noticed some old text survived in the begininng of section 4, removed that, some typos caught, probably twice as much added ;) - section 3, transport mappings clarified, section 3.1, UDP transport required [see issue 10] - maximum syslog message size is now 1280 bytes (I assume this *is* the minimum IPv6 MTU, had no time to check) [see issue 11] ... oops, sorry folks, accidently I removed the max size altogether ... shame on me for rushing. 1280 will be back in in -protocol-04 ;) - section 4.2 - MSG - now specifies UTF-8 including including all control characters [see issue 9] - section 4, TRAILER has been removed [see issue 6] - section 6, multi-part messages heavily changed. Name change from fragmentation to "multi-part messaging", more definitions, hopefully clearer description (some of the term names are *really* lenghty - advise on better terms is taken thankfully). - section 7, definition of structured data element IDs (and semantics) added - section 7.1 - time - tries to solve issue 12 - section 7.2 - orgin - tries to provide a way to preserve originator IP addresses inside the message. "origin" is also a key element when relay RFC 3164 operations will be described (I didn't manage to get this into the -03 version). - section 8, "relay operations" added, but so far it is more or less empty. - section 9, "security considerations" cleaned up. - section 9.1 - diagnostic logging - added as a security consideration. Comments on this are highly appreciated. This was not previously discussed on the WG mailing list I am looking forward to all comments. Rainer PS: I am unfortunately not able to attend the Seoul meeting personally, but Chris has agreed to act as proxy (thanks, Chris!)
