Subject: [AAA-WG]: OctetString type

From: David Frascone <[email-masked]>
Date: Sun, 28 Jan 2001 22:13:52 -0600

I think removing the basic string type was a bad idea.  With octet string,
there is no easy way to tell if the data is printable.  It was nice having
a string type, since the data could be printed in log messages, debug
strings, etc.

I think we should still have two types, Octets, and String, and treat them
appropriately.

Granted, on the transport side, DIAMETER will treat the two equaly, but it
makes debugging/logging much nicer to know when you can print out the
data involved.

Just my $.02 worth.

-Dave

---

From: Paul Funk <[email-masked]>
Date: Mon, 29 Jan 2001 12:36:53 -0500

I agree that String should be a type.

There will be numerous AVPs whose values must be human readable. In 
the text of the AVP's description, rather than specifying type as OctetString, 
then qualifying it to be "human readable UTF-8 character string", why not just 
just call a String a String?

A Diameter implementation needs to know an AVP's type not only for 
processing purposes but also for administrative purposes, e.g., logging 
and configuration. While it is always possible to qualify the use of an 
AVP further in its description, it promotes precision and clarity to formally 
define types for common data formats.

I think Time is also a candidate for re-inclusion as a data type. 

The Alpha-2 draft already defines the use of UTF-8 as a subset of 
OctetString, and time data as a subset of Unsigned32. They might as 
well be defined separately as types in their own right.