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



I share Victor's concerns on this one. I believe it may be safer not to
touch the meaning of Application-Id AVPs and they have always the same
values as the Application-Id in the message header.

My understanding of approach two was that Auth-App-Id (together with App-Id
in the header) is populated with the identifier of the corresponding
application, e.g. Gq.

  Thanks,
   Tolga

> -----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]
> >
> >


_______________________________________________
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.