Xml Mailing List: RE: Contributions for draft

[Mark Jones (mjones]

Dave,

I think we incorporated Brian Cain's proposal in coming up with the Command
element definition so he deserves a mention. Can't think of anyone else
though.

Regards,
       Mark

> -----Original Message-----
> From: xml-admin [at] frascone.com [mailto:xml-admin [at] frascone.com]On 
> Behalf Of
> David Frascone
> Sent: February 21, 2002 11:36 AM
> To: xml [at] frascone.com
> Subject: Re: [Xml Design Team] Contributions for draft
>
>
> 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
> >
> _______________________________________________
> Xml mailing list
> Xml [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/xml
>