Age | Commit message (Collapse) | Author |
|
Depending on the dictionary, generated dictionary modules may contain
unused functions included from diameter_gen.hrl. There may still be
warnings however since even used functions can contain code that
isn't reached for a given dictionary.
It would be useful for diameter to generate spec attributes for
a dictionary's generated records but the format of these is currently
undocumented.
|
|
Didn't quite interpret '*' as RFC 3588 dictates. In particular, the
interpretation depends on what's being qualified, a required, optional
or fixed AVP.
|
|
Writing a dictionary to file failed.
|
|
A value is required to be the same as any specified with
@avp_vendor_id but otherwise the two locations are equivalent.
Both possibilities are allowed since @avp_vendor_id is required
for AVPs of types other than Grouped (modulo it not really needing
to exist at all: see commit 943266c9) and since the grammar parsed
in @grouped (from RFC 3588) allows it.
|
|
|
|
@vendor is only required if the id is actually needed. That is, if
there is a locally defined AVP whose V flag is set and which does
not have a vendor id set by @avp_vendor_id.
Also, in the case of an inherited AVP, fix avp_name/2 in a generated
dictionary module defaulting vendor id from @vendor in the inheriting
dictionary but avp_header/1 defaulting it from the inherited dictionary.
In both cases the vendor id now defaults from @vendor in the inherited
dictionary.
Note that @avp_vendor_id from the inherited dictionary is
ignored: any changes from @vendor have to be explicit in the
inheriting dictionary. A better alternative to @avp_vendor_id
is to simply inherit from dictionaries setting the appropriate
@vendor but this was previously somewhat broken so @avp_vendor_id
was needed to set the id of an AVP whose definition was copied
from another source into a dictionary that only inherited from
the common dictionary (which doesn't set V on any AVPs).
|
|
|
|
The section simply results in generated macros and has nothing
specifically to do with result codes. It's still not documented,
and neither are the macros generated from @enum, since the generated
names are typically so long as to be impractical/unreadable in source.
Better to use numeric values with a comment or define your own
shorter macros as the need arises.
|
|
|
|
* anders/diameter/augment_inherited_enums/OTP-9469:
Allow @enum when AVP is defined in an inherited dictionary.
|
|
3GPP standards (for one) extend the values allowed for RFC 3588
AVP's of type Enumerated. Previously, extending an AVP was only
possible by completely redefining the AVP.
|
|
@id defines an application identifier and this is used only when sending
or receiving messages. A dictionary can define only AVP's however,
to be included by other dictionaries using @inherits, in which case it
makes no sense to require @id.
Note that message definitions are not inherited with @inherits, only
AVP's
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|