Re: [sip-clf] New CLF Syntax draft (text with index)

"Dean Willis" <> Thu, 07 May 2009 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B21723A6A55 for <>; Thu, 7 May 2009 13:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tlJ8u6YTQ3kN for <>; Thu, 7 May 2009 13:16:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D3B3B3A683D for <>; Thu, 7 May 2009 13:16:56 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5) with ESMTP id n47KIIPU019491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 7 May 2009 15:18:23 -0500
From: "Dean Willis" <>
To: Adam Roach <>
Date: Thu, 7 May 2009 15:18:21 -0500
Message-ID: <>
X-Mailer: EPOC Email Version 2.10
MIME-Version: 1.0
Content-Language: i-default
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sip-clf] New CLF Syntax draft (text with index)
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Dean Willis <>
List-Id: SIP Common Log File format discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 May 2009 20:16:57 -0000

Having indices and lenghts allows for aggregated fields (or sub-fields if you look at it that way ). Imagine serialing multiple structs, and being able to parse out a whole struct or a field within a struct.


-original message-
Subject: Re: [sip-clf] New CLF Syntax draft (text with index)
From: Adam Roach <>
Date: 05/07/2009 14:30

Simon Perreault wrote:
> Adam Roach wrote, on 07/05/09 03:20 PM:
>> I considered doing it both ways, but decided that I preferred the slight
>> space impact of being able to get to any fixed field by looking at only
>> two numbers instead of all the preceding fields. I'm open to doing just
>> lengths if people are very sensitive to the size of each record, but
>> have a personal preference for what's in the draft currently.
> I'm sorry, I don't understand. Why would one need to look at all the preceding
> fields?
> Let's say you want to look at field 3. You look up the third pointer (p3), this
> gives you the start of the field. Then you look up the fourth pointer (p4), this
> give you the end of the field. If you want the length you compute p4 - p3.

Ah, yes! That's a good point. I had considered encoding *lengths* only, 
which would require adding all the preceding fields together (and I had 
mis-read your suggestion to mean lengths instead of pointers). You are, 
of course, correct -- encoding only pointers gets me what I need, while 
cutting the index size in half. Thanks! I'll try to get a revised draft 
out reflecting this change sometime soon.

sip-clf mailing list