Actually, ya know we can combine this with something like Adam's draft. If you take the pcap entry format, and encode a "log" entry with the following header: | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ------------------------------------------------------------------------- | seconds | ------------------------------------------------------------------------- | microseconds | ------------------------------------------------------------------------- | saved_len | ------------------------------------------------------------------------- | orig_len | ------------------------------------------------------------------------- | all 0x00 | ------------------------------------------------------------------------- | 0x00 | 0x0800 | 0x4500 | ------------------------------------------------------------------------- | log_entry_len | seq_no | 0x000001 | 0x11 | ------------------------------------------------------------------------- | all 0x00 | ------------------------------------------------------------------------- | 0x00 | 0x0715 | 0x0715 | entry_len | ------------------------------------------------------------------------- | 0x00 | 0x04 | 0x00 | tot_len | 0x0000 | ------------------------------------------------------------------------- | all 0x00 | BEGIN | ------------------------------------------------------------------------- Then starting with the BEGIN bytes, you can record each Tag-Length-Value triple using the following: 1-Byte Type 1-byte Length (including type and length bytes) 1-255 bytes of chars And once again there would be plenty of tools/running-code which can already parse that today. :) Or we could do a slightly different variant of the "header", if you want TLV's which can be bigger/longer. -hadriel > -----Original Message----- > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf > Of Hadriel Kaplan > Sent: Thursday, March 26, 2009 3:57 PM > To: Vijay K. Gurbani; Adam Roach > Cc: sipping WG; draft-gurbani-sipping-clf@xxxxxxxxxxxxxx > Subject: Re: Alternate CLF syntax proposal > > > If the purpose of it is troubleshooting, or threat analysis type stuff, I > think the following format satisfies the needs as well: > http://wiki.wireshark.org/Development/LibpcapFileFormat > > The advantages: > 1) There's running code > 2) There's open source, on all operating systems, and also for commercial > use > 3) It's used by many people > 4) There are many tools which accept/process it > 5) It's fast to write/save > 6) It supports a sub-second timestamp > 7) It supports length encoding of packets, so you can skip past them > 8) It supports truncated saving of packets, so you don't have to save all > of very big ones > 9) It records the method name or response code very early in the saved log > entry for each packet > > Disadvantages: > 1) Nothing much new to specify, except to document it? > 2) It's a little tricky for SIP/TLS, where you basically have to create > fake segments/packets for the low layers, and same may be true for SIP/TCP > depending on when you record the log > 3) It doesn't provide a way to report internal system events/actions/info > (although we could fix that) > 4) Afaik, there is no specific remote push/streaming mechanism for it > defined (there was an attempt at it, but not final) > > -hadriel > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On > Behalf > > Of Vijay K. Gurbani > > Sent: Wednesday, March 25, 2009 10:58 PM > > > > Adam Roach wrote: > > > In the spirit of "send text," I've put together a straw-man proposal > for > > > an easy-to-generate and fast-to-process extensible format for saving > SIP > > > log messages: > > > > > > http://www.ietf.org/internet-drafts/draft-roach-sipping-clf-syntax- > > 00.txt > > [...] > > > > Adam: Essentially you are advocating for a table-of-content > > type of approach where you read the ToC and index straight > > to where you want to go. I have worked on SIP parsers > > designed this way. > > > > The parsing is optimized, yes, when compared to the ASCII > > version -- though perl can do wonders, but not to outperform > > binary parsing. The disadvantage is that you loose readability > > and would need specialized tools to, say, grep through such > > a file. > > > > It will be interesting to see what others think... > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > Web: http://ect.bell-labs.com/who/vkg/ > > _______________________________________________ > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > > Use sip@xxxxxxxx for new developments of core SIP > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
