Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-07.txt

Adam Roach <> Tue, 23 October 2012 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 070531F0C96 for <>; Tue, 23 Oct 2012 14:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.194
X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GFaJDeuXaVJd for <>; Tue, 23 Oct 2012 14:31:44 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id E498A1F0C95 for <>; Tue, 23 Oct 2012 14:31:42 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q9NLVawX047236 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 23 Oct 2012 16:31:37 -0500 (CDT) (envelope-from
Message-ID: <>
Date: Tue, 23 Oct 2012 16:31:36 -0500
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Gonzalo Salgueiro <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080205060305070604080501"
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: " Mailing" <>
Subject: Re: [sip-clf] I-D Action: draft-ietf-sipclf-format-07.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Common Log File format discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Oct 2012 21:31:45 -0000

On 10/4/12 21:13, Oct 4, Gonzalo Salgueiro wrote:
> Folks:
> I have posted the -07 version of the SIP CLF Format Draft and it is now in the archives at [1].
> This draft was meant to address the few remaining AD review items that were raised. The diffs between the -06 and the -07 versions are at [2]
> The principal changes include:
> - Introduced Base64 Encoded Byte (BEB) to deal with optional logging of non-UTF-8 message bodies

I think the text is a bit confused on what UTF-8 means. The phrase "any 
characters outside the UTF-8 character set" appears many times, and I'm 
afraid it doesn't really make any sense.

What you probably want to do is define a term somewhere in the document 
to formally specify "Those Things That Must Be Base-64 Encoded". I would 
recommend something like:

"For the purposes of this document, we define 'unprintable' to mean a 
string of octets that: (a) contains an octet with a value in the range 
of 0 to 31, inclusive; (b) contains an octet with a value of 127; or (c) 
contains any series of octets greater than or equal to 128 which do not 
form a valid UTF-8 sequence, as specified by [UNICODE]."

Then, your statements become far simpler; for example: "The Value field 
for the optional element being logged MUST be Base64 encoded if it is 
unprintable." And: "For an optionally logged message body (Tag=01) the 
BEB is set according to whether the message body is unprintable." And: 
"When optionally logging an entire SIP message (Tag=02) the BEB is set 
according to whether the message body portion is unprintable."

You get the idea.


P.S. The above definition would require adding a reference for 
[UNICODE], like so:

    [UNICODE] The Unicode Consortium. The Unicode Standard,
              Version 6.2.0, (Mountain View, CA: The Unicode
              Consortium, 2012. ISBN 978-1-936213-07-8)