Subject: Re: [AAA-WG]: OctetString type

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Feb 2001 17:06:30 +0100

>>>>> Paul Funk writes:

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

Formally define the type in the AVP definition by using a proper data
definition language. With SMIng, you can easily define that this AVP
is a Utf8String or something else you need to introduce. You do not
need all the type information in the protocol layer.

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

The key here is that the protocol should be stable and thus work with
a minimalistic set of types.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: "Nelson, David" <[email-masked]>
Date: Thu, 1 Feb 2001 17:40:28 -0500

Dave Frascone writes...

> So, can we have a pseudo-vote?  Does anyone NOT want a printable-vs-
> unprintable string type for AVPs?

This seems reasonable to me.  I thought we weren't supposed to let the
data modeling efforts impact the on-the-wire protocol?  I would not
call printable string a complex type, any more than float is a complex
type.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: [email-masked]