Subject: [sip-clf] Strawman proposal to handle bodies

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 19 Jan 2011 10:29:25 -0600

Folks: In the virtual meeting we had this morning, I volunteered
to draft a proposal for handling message bodies.

As I understand it, the bounds are that logging bodies is optional
and that bodies should not be logged as vendor extensions as that
will hinder interoperability.

Furthermore, we are interested in logging different body types,
or more concretely bodies containing:

   - SDP (Content-Type: application/sdp)
   - XML payloads (Content-type: application/*+xml)
   - binary (Content-Type: application/{isup,qsig})
   - miscellaneous text content (Content-type: message/sipfrag,
     message/http, text/plain, ...)

To support this, we reserve a tag field for bodies as described
in [1], say 0x0004.  The value of this tag field would be the
content type itself plus the body.

To take a concrete example,

    Type: 0x0004
    Length: 160
    Value: application/sdp v=0\r\no=alice 2890844526 2890844526 IN IP4
     host.atlanta.example.com\r\ns=\r\nc=IN IP4
     host.atlanta.example.com\r\nt=0 0\r\n
     m=audio 49170 RTP/AVP 0 8 97\r\n

Couple of points to note: (a) the MIME type is saved in the Value;
(b) the octets in Value are all logically on one line; (c) the
Length includes the payload + length of the MIME type + LWS separator
between the MIME type and the content.

Also note that for now let's keep aside the \r\n tokens delimiting
the lines in the example above.  Once we agree to the proposal, we
can work the details out on how to represent \r\n in a text-based
body.

Binary bodies would have to be byte encoded to render them in the
ASCII file.

Please comment on this approach so I can update the problem statement
and Gonzalo can start thinking about the representation format for
these in [1].

[1] http://tools.ietf.org/html/draft-salgueiro-sipclf-indexed-ascii-02

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Jan 2011 10:55:21 +0100

Vijay,

Don't we need 4 different tags for the 4 content types we plan to support? Otherwise you have to decode part of the value to see how the rest of the value is encoded, IIUC.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: 19 January 2011 16:29
> To: [email-masked]
> Subject: [sip-clf] Strawman proposal to handle bodies
> 
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf
>

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 20 Jan 2011 05:56:23 -0500

Hi Vijay, 

Thanks for getting this on the list so fast.

This works for me. 

(As for John's comment, I can live with having to decode the content type as opposed to trying to enumerate them).

Peter Musgrave
(as individual)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Jan 2011 08:32:32 -0600

On 01/20/2011 03:55 AM, Elwell, John wrote:
> Vijay,
>
> Don't we need 4 different tags for the 4 content types we plan to
> support? Otherwise you have to decode part of the value to see how
> the rest of the value is encoded, IIUC.

John: Thanks for your time; indeed, that was my intent.

Having four different content types is one way to go, but
since what is contained in this field is a body, then it also
seems appropriate to have a tag for a body and insert the
corresponding MIME type in the record to describe the body.

In this manner, everything is self-described using the one
body tag as compared to enumerating a separate tag for each
body type.

Will this approach work for you?

Thanks,

- vijay

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Jan 2011 15:40:40 +0100

Vijay,

I don't object strongly - just wanted to solicit other opinions.

John

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 20 January 2011 14:33
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [sip-clf] Strawman proposal to handle bodies
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Jan 2011 08:56:22 -0600

> I don't object strongly - just wanted to solicit other opinions.

John: OK, thanks.

Note that one small advantage of having the one tag is that it
makes it easy to handle multipart bodies since the MIME type
plus boundary parameter is saved in the CLF record.  With an enumerated
tag set, we'd need to reserve a special tag for multipart and
somehow save the boundary parameter in the CLF record.

If you can think of a reason why going with one tag may prove
problematic, please let me know.  As far as I can see it, I think
it should work.

Thanks,

- vijay

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 27 Jan 2011 06:24:07 -0500

SIP-CLFers. 

It would be good to hear from a few more people on this issue!

This appears to be the final substantive issue to getting the next round of docs out (and hopefully then into WGLC). 

Peter Musgrave
(as chair)