-----Original Message-----
From: Victor Fajardo [mailto:vfajardo at tari.toshiba.com]
Sent: Tuesday, December 12, 2006 12:22 PM
To: Tom-PT Taylor
Cc: Tolga Asveren; dime at ietf.org
Subject: Re: [Dime] Application Id for commands in Gq and similar
applications
Hi Tom,
You saw my other note suggesting a change in the meaning of the
application identifier in the body?
I see. My main concern was interoperability if this new "meaning"
results in multiple different app ids within a message. It could
generate issues.
best regards,
victor
I thought I would do some forensic tracking, and dug out a copy of
draft-calhoun-diameter-04.txt (July 1998) that's still lurking on my
laptop. (We used it as a basis for IPDC, one of Megaco's
predecessors.) Anyway, that was too far back -- the concept of
applications wasn't present yet.
Victor Fajardo wrote:
Hi Tom,
Despite what I just said, I'll go for the second approach for the
sake of maximizing the possibility of interoperability.
Just trying to catch up on the discussion, does the "second approach"
mean that the app id in the header does not match those in the app id
avps ? If so, this is probably in conflict with the existing base and
with the bis as well. My understanding is that if your just trying to
reuse a command/message defined from another spec (pls correct me if
I mis-understood the problem) then the "second approach" is preferred
but you should define a consistent app id in both the header and app
id avps. The app id of the spec that originally defined the command
need not be represented when you use the command in your new
application.
[snip]
The other
possibility might conform more to the spirit underlying RFC 3588 by
using Auth-Application-Id to convey the application identifier
(like Gq
and the RFCs), keeping all the mandatory AVPs, but
specifying default
contents for those mandatory AVPs of no interest to the application.
[snip]
