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

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 May 2009 15:18:21 -0500

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.

--
Dean

-original message-
Subject: Re: [sip-clf] New CLF Syntax draft (text with index)
From: Adam Roach <[email-masked]>
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.

/a
_______________________________________________
sip-clf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-clf

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 May 2009 07:16:11 +0200

Hi,

I haven't followed the what-encoding-to-use discussion in detail (I
don't have any personal preference), and I appologise if the following
has already been discussed.

Have people taken into consideration the text in the body handling
draft, which says that binary data in message bodies SHOULD be
transfered using "pure" binary encoding.

I know what we are not talking about a message body type now, but do we
want SIP entities to have to support different kind of binary encodings?
They may of course have to do that anyway, if they support protocols etc
outside our control, but still...

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 7. toukokuuta 2009 23:18
> To: Adam Roach
> Cc: [email-masked]
> 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.
> 
> --
> Dean
> 
> -original message-
> >> 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 08 May 2009 08:54:21 -0500

> outside our control, but still...

Christer: For CLF purpose, if a binary body is to be logged,
it seems appropriate to uuencode it or something along those
lines, no?  Or am I missing the point of your question?

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/

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 19 May 2009 13:46:24 +0200

Hi, 

>>I know what we are not talking about a message body type now, but do 
>>we want SIP entities to have to support different kind of binary
encodings?
>>They may of course have to do that anyway, if they support protocols 
>>etc outside our control, but still...
> 
>lines, no?

Why?

>Or am I missing the point of your question?

My question was why we choose to different binary encoding (no matter
what we are logging) than we use in binary message bodies.

Regards,

Christer