Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.

Michael Demmer <> Wed, 25 May 2005 16:39 UTC

Received: from pisco (pisco.CS.Berkeley.EDU []) by (8.11.6/8.11.6) with ESMTP id j4PGdjV31203 for <>; Wed, 25 May 2005 09:39:45 -0700
Received: from demmer by pisco with local (Exim 4.50) id 1Dayv3-000494-60; Wed, 25 May 2005 09:39:45 -0700
Date: Wed, 25 May 2005 09:39:45 -0700
From: Michael Demmer <>
Cc: "Susan F. Symington" <>, "'Howard Weiss'" <>
Subject: Re: (dictionary or not) Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
Message-ID: <>
References: <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.2i
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: DTN Security Discussion <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>

> Aha!  Ok, it can work that way so long as there're no I18N
> problems there (there aren't, right?).

Well -- we need to decide on what to do re I8N. My inclination is to
have the protocol just be in ASCII, and put the burden on the
application interface to go to/from some multibyte encoding when
interfacing with the application.

> Personally, I think I'd rather that dictionary entries contain
> a length field (whatever encoding) since I've found lists of
> null-terminated strings are a great source for implementation
> errors.

Yeah -- I just feel like it's not worth the bytes. My other thought is
that we can infer the string lengths based on the various offsets
scattered throughout the bundle, in other words, if all the offsets
(i.e. src, dest, custodian, etc) were sorted, we could then infer the
various lengths based on the differences. But this is probably harder
to read (though more efficient) than just scanning for the null.