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

Peter Musgrave <peter.musgrave@magorcorp.com> Thu, 27 January 2011 11:21 UTC

Return-Path: <peter.musgrave@magorcorp.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65BD3A68E8 for <sip-clf@core3.amsl.com>; Thu, 27 Jan 2011 03:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.237
X-Spam-Level:
X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_URI_EQUALS=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PagYwRPEMMdZ for <sip-clf@core3.amsl.com>; Thu, 27 Jan 2011 03:21:08 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 45E993A688E for <sip-clf@ietf.org>; Thu, 27 Jan 2011 03:21:07 -0800 (PST)
Received: by iwn40 with SMTP id 40so2045833iwn.31 for <sip-clf@ietf.org>; Thu, 27 Jan 2011 03:24:11 -0800 (PST)
Received: by 10.42.220.73 with SMTP id hx9mr1900768icb.521.1296127450951; Thu, 27 Jan 2011 03:24:10 -0800 (PST)
Received: from [192.168.1.100] ([204.237.32.134]) by mx.google.com with ESMTPS id k42sm12411448ick.8.2011.01.27.03.24.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 03:24:10 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Peter Musgrave <peter.musgrave@magorcorp.com>
In-Reply-To: <4D371165.5030104@bell-labs.com>
Date: Thu, 27 Jan 2011 06:24:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9EA1890C-50D1-4066-B23F-8166721BC368@magorcorp.com>
References: <4D371165.5030104@bell-labs.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
X-Mailer: Apple Mail (2.1082)
Cc: "sip-clf@ietf.org" <sip-clf@ietf.org>
Subject: Re: [sip-clf] Strawman proposal to handle bodies
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jan 2011 11:21:10 -0000

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)


On 2011-01-19, at 11:29 AM, Vijay K. Gurbani wrote:

> 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} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf