Re: [Dime] Application Id for commands in Gq and similar applications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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]




_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.