Re: [Rfid] Re: XML vs. Text vs. Binary

Scott Barvick <sbarvick@revasystems.com> Fri, 22 July 2005 12:08 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvwKK-000875-27; Fri, 22 Jul 2005 08:08:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvwKI-00085h-Oc for rfid@megatron.ietf.org; Fri, 22 Jul 2005 08:08:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06840 for <rfid@ietf.org>; Fri, 22 Jul 2005 08:08:24 -0400 (EDT)
Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvwoX-0002Qb-7M for rfid@ietf.org; Fri, 22 Jul 2005 08:39:41 -0400
Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 08:08:04 -0400
Subject: Re: [Rfid] Re: XML vs. Text vs. Binary
From: Scott Barvick <sbarvick@revasystems.com>
To: j.schoenwaelder@iu-bremen.de
In-Reply-To: <20050722113349.GA21188@boskop.local>
References: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> <20050722113349.GA21188@boskop.local>
Content-Type: text/plain
Message-Id: <1122034083.26431.32.camel@saco.revasystems.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2)
Date: Fri, 22 Jul 2005 08:08:03 -0400
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jul 2005 12:08:04.0104 (UTC) FILETIME=[03554880:01C58EB6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 7bit
Cc: rfid@ietf.org
X-BeenThere: rfid@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Control and Access of Infrastructure for RFID Operations Discussion List <rfid.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rfid>
List-Post: <mailto:rfid@lists.ietf.org>
List-Help: <mailto:rfid-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rfid>, <mailto:rfid-request@lists.ietf.org?subject=subscribe>
Sender: rfid-bounces@lists.ietf.org
Errors-To: rfid-bounces@lists.ietf.org

It is probably important to point out on this thread as well that
security and human readability are mutually exclusive, and security
needs will trump human readability (including binary decodes through
open source, free tools such as Ethereal) any day.   So designing for
human readability in what is inherently machine-to-machine operation
does not seem like a requirement, especially if RFID deployments grow
the way we all believe they will.

Scott

On Fri, 2005-07-22 at 07:33, Juergen Schoenwaelder wrote:
> On Fri, Jul 22, 2005 at 06:56:14AM -0400, Scott Barvick wrote:
> > Stephane,
> >  
> > From the security perspective, the protocol processing is layered on 
> > top of standard security mechanisms as discussed in Section 4.2 of 
> > the draft.  Therefore, the implementation can safely access fields 
> > in payload as efficiently as possible.
> 
> I will leave it to implementors to decide whether they want to be 
> robust against broken implementations or not. However, I like to point 
> out two things:
> 
> a) As long as security processing is done in software, this will weight
>    more than any encoding/decoding required, whether that is a binary
>    format or not does not matter.
> 
> b) Our SNMP experience is that encoding/decoding is not at all an
>    issue when it comes to the amount of CPU cycles burned. Most of 
>    the time is spend accessing the instrumentation and in the security 
>    processing (if enabled). So if you want to optimize CPU usage, 
>    make sure you look at the whole system and spend the efforts
>    where you can maximize the benefit.
> 
> Human readability is a major enabling factor. In theory, all you need 
> is a decent library to handle binary encodings well but in the real 
> world it seems to help if people can do things without relying on 
> such a library. Human readable encodings (and I include XML here) 
> simply enable more people to get into the "game" and this is 
> ultimately driving the success of a technology.
> 
> /js


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid