... Except for the fact that many AVP names start with "3GPP".
Make the AVP names XML IDs again.
Fix all the grouped AVPs that reference AVPs (by name) or vice-versa. This
includes:
* Fixing a bunch of typos (including type mismatches).
* Commenting out a number of references to vendor AVPs for which we don't have
the specs.
* Adding a few missing AVPs.
Change-Id: Ic2ddb50cc947877de9086be51f7813e8f9be02b4
Reviewed-on: https://code.wireshark.org/review/15973
Reviewed-by: Anders Broman <a.broman58@gmail.com>
In some cases this means using the correct (updated?) name from the
specification. In others it means prepending the application- or vendor-name
to force uniqueness.
Remove a few more "Unassigned" AVPs from the XML files.
Change-Id: I61d55ef97ff8efc3317c91bf79e73031735f740a
Reviewed-on: https://code.wireshark.org/review/15949
Reviewed-by: Anders Broman <a.broman58@gmail.com>
There's no AVP named "AVP". And there's no need to tell Wireshark that any AVP
may put in the group (the RFC lists "AVP" for that purpose).
Change-Id: I3591af725ebe089e13eae7b712ef4404cb7924a2
Reviewed-on: https://code.wireshark.org/review/15906
Reviewed-by: Anders Broman <a.broman58@gmail.com>
AVPs can be grouped by Vendor now (not just by Application).
Move a bunch of vendor-specific Application IDs to the vendor's XML file.
Delete the (basically empty) SKT.xml, ChinaTelecom.xml, and VerizonWireless.xml
files.
Fix a typo: 16777224 is 3GPP Gx, not 3GPP Cx.
Use (derived) type Enumerated (rather than Unsigned32 or Integer32) when the
AVP is of type Enumerated.
Change-Id: I7a9702c0c48dc3fe751ad74413d8ecc040984f1f
Reviewed-on: https://code.wireshark.org/review/8235
Petri-Dish: Jeff Morriss <jeff.morriss.ws@gmail.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Consistently used (derived) type Enumerated (rather than Unsigned32 or
Integer32) when the AVP is of type Enumerated.
Use a uri of "none" when we don't have access to the specification.
Update the URI of an Application or two.
Clean up white space and formatting.
Change-Id: Iad677db186469b7d8c4a23b7a7fca6c357dbc012
Reviewed-on: https://code.wireshark.org/review/8164
Reviewed-by: Jeff Morriss <jeff.morriss.ws@gmail.com>
the lines of what's done for RADIUS. That keeps them together (and
separate from other files), and makes the layout of the top-level source
directory closer to the layout of the installation directory, so that if
you run Ethereal or Tethereal from the top-level directory on Windows
it'll pick up the Diameter dictionary files (if it supports loading
them), and can do so on UN*X if we support a mechanism to let it find
its control files in the directory in which the binary resides.
Use the diameter_DATA, dtds_DATA, and radius_DATA macros in the
EXTRA_DIST macro, so you only have to change the lists of Diameter, DTD,
and RADIUS files in one place if you add or remove a file.
svn path=/trunk/; revision=16050
Jeff Morriss