Re: [sip-clf] AD review: draft-ietf-sipclf-format-06

Robert Sparks <rjsparks@nostrum.com> Thu, 12 July 2012 22:35 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: sip-clf@ietfa.amsl.com
Delivered-To: sip-clf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCD411E80A5 for <sip-clf@ietfa.amsl.com>; Thu, 12 Jul 2012 15:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Level:
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh0g62cqdJ42 for <sip-clf@ietfa.amsl.com>; Thu, 12 Jul 2012 15:35:52 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C075711E8098 for <sip-clf@ietf.org>; Thu, 12 Jul 2012 15:35:52 -0700 (PDT)
Received: from unexplicable.local (pool-173-71-47-121.dllstx.fios.verizon.net [173.71.47.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q6CMaPqs088754 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 12 Jul 2012 17:36:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <4FFF5169.6040108@nostrum.com>
Date: Thu, 12 Jul 2012 17:36:25 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Gonzalo Salgueiro <gsalguei@cisco.com>
References: <4F9EE0A4.2000905@nostrum.com> <BABA3C82-D90C-422D-A285-9E2902334573@cisco.com> <4FDA2807.6080802@nostrum.com> <066F0992-9BFD-4CC2-81FF-0697529E179F@cisco.com>
In-Reply-To: <066F0992-9BFD-4CC2-81FF-0697529E179F@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 173.71.47.121 is authenticated by a trusted mechanism)
Cc: "sip-clf@ietf.org Mailing" <sip-clf@ietf.org>
Subject: Re: [sip-clf] AD review: draft-ietf-sipclf-format-06
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 12 Jul 2012 22:35:53 -0000

Trimming to one point and replying inline. (Your proposals for 
everything else are fine).

On 7/12/12 4:40 PM, Gonzalo Salgueiro wrote:
>
>>>> 2) The description of escaping and encoding in Tag=01 is still ambiguous. You say you must base64 encode any binary body. You also say you must escape CRLFs. I suspect you intend for those to be mutually exclusive? What are you expecting the implementer to use to decide if the body is binary or not? We should be making much more precise use of the terms defined in the media type specifications to make this clear (to avoid things like encoding a body that's already encoded).
>>> Our intent is to be clear that CRLFs are to be escaped for ANY body type. Is your question about order of operations in regards to escaping CRLFs and base64 encoding a binary body  (something like MIME types of application/ISUP and application/QSIG)?
>> application/jpg. Are you going to escape bits of a compressed picture that just happen to contain the CRLF sequence or not? What part of the text makes that clear?
> I think I get what you are hinting at but I need to play it back to you for verification. The current text states:
>
> =====
> ...Note that binary bodies MUST be base64encoded to render them in the SIP CLF log file.
>
> If an optionally logged SIP message body contains any CRLFs they MUST be escaped by using the URI encoded equivalent value of "%0D%0A".  This escaping mechanism applies to all body  types.
> =====
>
> So we don't make any distinction in treatment between the various possible body types. I don't believe that we should.
You want to base64 application/jpg, but (generally) not application/sdp 
(It's possible to have non-ASCII range UTF-8 characters in SDP - would 
you encode such a body?)

> I think what the document may be missing to make this escaping mechanism clear is the order of operation. I believe I need to explicitly state that the translation to base64 must occur before the escaping. This would eliminate any ambiguity about the possibility of ever having the escaped CRLF sequence of %0D%0A.
>
> To your specific point, if a binary body (like an image) is present then it would have to be base64 encoded first and that base64 character stream could never include the CRLF escape sequence of %0D%0A because '%' is not a valid base64 character. Would this clarification in the text around order of operation address the ambiguity in escaping base64 encoded binary bodies?
>
>
Making it clear that these are performed in that order is good.
Including an example in the draft that shows the result of applying that 
ordering will help.

But I don't think we've discussed the part of my original question that 
had to do with how an implementation decides whether the type it's 
looking at is "binary" or not.
What is the thing to look at that tells you to treat application/jpg 
different from application/sdp, and that different from an sdp body that 
contains some thing out of the ascii range? Just looking at the media 
type isn't going to be enough.

Is what you're really trying to say is "base64 encode any body that 
contains an octet outside <some limited range>"?  If so, you need 
something in the message that tells you that you've done this encoding.

RjS