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

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: sip-clf-bounces@ietf.org 
> [mailto:sip-clf-bounces@ietf.org] On Behalf Of Dean Willis
> Sent: 7. toukokuuta 2009 23:18
> To: Adam Roach
> Cc: sip-clf@ietf.org
> Subject: Re: [sip-clf] New CLF Syntax draft (text with index)
> 
> 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 <adam@nostrum.com>
> 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
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf
> 
> 
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf
> 