Xml Mailing List: Re: Contributions for draft

[David Frascone (dave]

Anything for the acknowledgments section?  Right now, it has:

I'd like to thank yatta yatta yatta.



On Sunday, 10 Feb 2002, Mark Jones wrote:
> Dave,
> 
> I think we should consider pulling the "base", "application" and "command"
> sections forward in the document so that the order matches their appearance
> in the XML file. What do you think?
> E.g.
>       3.0  Dictionary Layout
>          3.1  Vendor Element
>          3.2  Base Element
>          3.3  Application Element
>          3.4  Command Element
>          3.5  AVP Rule Element
>          3.6  Type Definition Element
>          3.7  Attribute Value Pair Element
>          3.8  Type Element
>          3.9  Grouped AVPs Element
>          3.10 Enumerated Element
> 
> I also noticed that the "type" element section is missing from the draft.
> 
> ---
> (Section numbers refer to existing draft)
> 
> 3.0 Dictionary Layout
> 
> The root or top-level element of a Diameter dictionary is the "dictionary"
> element. The dictionary element contains zero or more "vendor" elements, the
> "base" element and zero or more "application" elements.
> 
> The top-level XML file containing the "dictionary" element SHOULD be named
> "dictionary.xml". Each "application" element SHOULD be defined in a separate
> XML file and referenced from the top-level XML file using an external entity
> declaration.
> 
> 3.3  Enumerated Types Element
> 
> The enum element defines a name to value mapping for use in encoding and
> decoding   AVPs of type Unsigned32.
> 
> (together with your example, I think this is all we need here.)
> 
> 3.4  Attribute Value Pairs
> 
> The avp element completely defines one Attribute Value Pair and is the most
> frequently used element in the dictionary. The avp element contains either a
> type element, or a grouped element, and zero or more enum elements together
> with attributes that completely define the AVP including format and flags.
> 
> 3.4.3 "code" Attribute
> 
> The "code" attribute defines the integer value used to encode the AVP for
> transmission on the network.
> 
> 3.5  Grouped AVPs
> 
> The grouped element is used define an AVP which encapsulates a sequence of
> AVPs together as a single payload.
> 
> 3.6  AVP Rules
> 
> The requestrules and answerrules elements define the placement of key AVPs
> within request and answer commands respectively. These elements may be used
> to perform syntax checking at the protocol layer.
> 
> 3.6.1 "name" Attribute
> 
> This rule applies to the previously defined AVP with the matching "name"
> attribute.
> 
> 3.x Base Protocol Element
> 
> The base element defines the commands, data types and AVPs that are part of
> the Diameter Base Protocol [1].
> 
> 3.x Application Element
> 
> One of the ways in which the Diameter protocol can be extended is through
> the addition of new applications. The application element defines the new
> Commands, Types or AVPs needed to support a new Diameter application. It may
> also reference elements defined in the base protocol.
> 
> 3.x Type Element
> 
> The type element defines the data type of the AVP in which it appears. This
> element MUST appear in all non-grouped AVP definitions.
> 
> 3.x.1 "type-name" attribute
> 
> The "type-name" attribute contains the data type name. This attribute is of
> type IDREF and MUST refer to the "type-name" value of a previously defined
> "typedefn" element.
> 
> ---
> 
> Regards,
>        Mark
> 
> _______________________________________________
> Xml mailing list
> Xml [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/xml
>