Actually It appears not to be so:
In the very fresh
http://tools.ietf.org/html/draft-ietf-dime-diameter-api-02 you find:
"
3.4.4.1. AAADictionaryEntryFromAVPCode()
This function looks up a dictionary entry using a command code and a
vendor id:
AAAReturnCode
AAADictionaryEntryFromAVPCode(AAA_AVPCode avpCode,
AAAVendorId vendorId,
AAADictionaryEntry *entry);
"
Has no reference whatsoever to an applicationId of any sort, that
would made the world flat (and the code much simpler :-).
Infact http://tools.ietf.org/html/rfc3588#section-11.1.1
States that:
"
There are
multiple namespaces. Vendors can have their own AVP Codes namespace
which will be identified by their Vendor-ID (also known as
Enterprise-Number) and they control the assignments of their vendor-
specific AVP codes within their own namespace.
"
Which implicitly says that is AVP-code and vendor-id alone to uniquely
identify an AVP. Why the F one has to infer this from a statement in
the "IANA Considerations" section of the RFC is open for discussion.
Luis
On 7/13/07, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> wrote:
Are there really any cases where AVPs have the same code and the same
vendor ID but different meanings under different application IDs?
There are plenty of places in the 3GPP specs where an AVP defined in
one interface/application id is used in another one. Would you only
use the app id to disambiguate?
Martin
On 7/13/07, bugzilla-daemon@xxxxxxxxxxxxx <bugzilla-daemon@xxxxxxxxxxxxx> wrote:
> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1494
>
>
> luis.ontanon@xxxxxxxxx changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Status|NEW |ASSIGNED
>
>
>
>
> --
> Configure bugmail:
> http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> _______________________________________________
> Wireshark-bugs mailing list
> Wireshark-bugs@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-bugs
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
