Re: [Dime] Diameter Group: Type?

Ivan Skytte Jørgensen <isj-dime@i1.dk> Tue, 25 January 2011 11:38 UTC

Return-Path: <isj-dime@i1.dk>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55063A63C9 for <dime@core3.amsl.com>; Tue, 25 Jan 2011 03:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.688
X-Spam-Level:
X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LT953z1FSZY for <dime@core3.amsl.com>; Tue, 25 Jan 2011 03:38:28 -0800 (PST)
Received: from i1.dk (port80.ds1-hk.adsl.cybercity.dk [212.242.60.147]) by core3.amsl.com (Postfix) with ESMTP id AB1C13A6A70 for <dime@ietf.org>; Tue, 25 Jan 2011 03:38:28 -0800 (PST)
Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id 3AB175C0095 for <dime@ietf.org>; Tue, 25 Jan 2011 12:41:24 +0100 (CET)
Received: from isjsys (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTP for <dime@ietf.org>; Tue, 25 Jan 2011 12:41:24 +0100 (CET)
From: Ivan Skytte Jørgensen <isj-dime@i1.dk>
To: dime@ietf.org
Date: Tue, 25 Jan 2011 12:41:03 +0100
User-Agent: KMail/1.9.10
References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com>
In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com>
X-Accept-Language: da, en, de
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201101251241.04033.isj-dime@i1.dk>
Subject: Re: [Dime] Diameter Group: Type?
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jan 2011 11:38:29 -0000

On Monday 24 January 2011 14:51:27 Erez Nassimi wrote:
> Dealing with the Diameter standard for more than 2 years, I always
> had the following question, I never dared to ask. But even after 2
> years, I do not seem to have a good answer for it:
>
> In RFC 3588, section 4.2 - AVP Data Formats, "Grouped" is defined
> as a "basic type". Doesn't it make more sense to set a flag for
> Grouped AVP in flags section? Group may be basic but it is not a
> real type. It's just an indication of a complex data structure.
>
> If "Grouped" is defined as a flag, it will simplify any parser's
> work - and performance is such a rare resource.

The payload format of an AVP is uniquely identified by the AVP code. 
This means that if you receive an unknown AVP then the only thing you 
can do is to check the M-bit. If the M-bit is unset then you must 
skip it. If the M-bit is set then the message must be failed. Knowing 
if the unknown AVP is actually a grouped AVP does not help you.

If the hypothetical "G-bit" existed and was set on an unknown AVP why 
would the parser try to parse it?

The only area I can think of where the hypothetical G-bit would help 
is when trying to parse raw TCP streams without knowing the 
vendor/application/specification (eg. wireshark) and the G-bit could 
help to parse the grouped AVPs for human inspection.

/isj