| It's input time guys. | <– Date –> <– Thread –> |
From: David Frascone (dave frascone.com)
|
|
| Date: 28 Jan 2002 14:24:27 -0000 | |
The draft is as done as I can do on my own. It's time for you to review and catch my errors. Also, I need you to either fill in your contact information, or send it to me so I can update it for you. Attached are the nroff, text and pdf versions. The pdf has really nice tables, but the formatting is a bit screwed up. Guess I need to get a little better at writing device independant nroff :) -Dave
.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Frascone et al.
.ds RF [Page %]
.ds CF expires June 2002
.ds LH Internet-Draft
.ds RH January 2002
.ds CH
.hy 0
.ad l
.nf
AAA Working Group David Frascone
Internet-Draft Sun Microsystems, Inc.
Category: Informational Mark Jones
Bridgewater Systems
Eric Guttman
Sun Microsystems, Inc.
January 2002
.fi
.sp 2
.ce 2
Diameter XML Dictionary
<draft-ietf-aaa-xml-dictionary-00.txt>
.sp 2
.in 0
Status of this Memo
.in 3
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
.in 6
http://www.ietf.org/ietf/1id-abstracts.txt
.in 3
The list of Internet-Draft Shadow Directories can be accessed at:
.in 6
http://www.ietf.org/shadow.html.
.in 0
Copyright Notice
.in 3
Copyright (C) The Internet Society 2002. All Rights Reserved.
.in 0
Abstract
.in 3
This document describes a coding Diameter dictionaries in XML. This coding
is intended for use by Diameter implementations to represent Applications,
Comands, Vendors, and AVPs.
.in 0
Discussion of this document
.in 3
Send comments to the AAA Working Group mailing list <aaa-wg [at] merit.edu>.
To subscribe to the list, send a message with the body 'subscribe aaa-wg'
to <majordomo [at] merit.edu>
.nf
.in 0
Table of Contents
.in 6
1.0 Introduction
2.0 Specifications and Requirements
3.0 Dictionary Layout
.in 9
3.1 Vendors Container
.in 12
3.1.1 vendor Attribute "id"
3.1.2 vendor Attribute "name"
.in 9
3.2 Type Definition Container
.in 12
3.2.1 typedefn Attribute "type-name"
3.2.2 typedefn Attribute "type-parent"
3.2.3 typedefn Attribute "description"
.in 9
3.3 Enumerated Types Container
.in 12
3.3.1 enum Attribute "name"
3.3.3 enum Attribute "code"
.in 9
3.4 Attribute Value Pairs
.in 12
3.4.1 avp Attribute "name"
3.4.2 avp Attribute "description"
3.4.3 avp Attribute "code"
3.4.4 avp Attribute "may-encrypt"
3.4.5 avp Attribute "mandatory"
3.4.6 avp Attribute "protected"
3.4.7 avp Attribute "vendor-id"
.in 9
3.5 Grouped AVPs
.in 12
3.5.1 gavp Attribute "name"
3.5.2 gavp Attribute "vendor-id"
.in 9
3.6 AVP Rules
.in 12
3.6.1 avprule Attribute "name"
3.6.2 avprule Attribute "position"
3.6.3 avprule Attribute "maximum"
3.6.4 avp Attribute "minimum"
.in 9
3.7 Commands
.in 12
3.7.1 command Attribute "name"
3.7.2 command Attribute "code"
3.7.3 command Attribute "vendor-id"
.in 9
3.8 Applications and Base Protocol
.in 12
3.8.1 application and base Attribute "id"
3.8.2 application and base Attribute "name"
3.8.3 application and base Attribute "uri"
.in 6
4.0 References
5.0 Acknowledgments
6.0 Authors' Addresses
Appendix A. Document Type Definition
Appendix B. DTD & Dictionary Links
.fi
.TS
.TE
.bp
.in 0
1.0 Introduction
.in 3
Diameter [1] is an extensible protocol used to provide AAA services
to different access technologies. To maintain extensibility, Diameter
uses a dictionary to provide it with the format of commands and AVPs.
This document describes the representation of the Diameter dictionary
using XML [2].
.in 0
2.0 Specifications and Requirements
.in 3
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [3].
.in 0
3.0 Dictionary Layout
.in 3
The dictionary is composed of several XML files, liked together
with external entity tags. In the top level file (which SHOULD
be called "dictionary.xml"), Vendors, types, and the base protocol
are defined. Other applications SHOULD be defined in other external
entity files.
Syntax:
.nf
.in 6
<!ELEMENT dictionary (
.in 12
vendor*,
base,
application*)>
.fi
.TS
box;
c|c
l|r.
Element Classification
=
vendor Zero or More
_
base Required
_
application Zero or More
.TE
.in 0
3.1 Vendors Container
.in 3
The Vendor container defines a vendor, and associates it's name with a
vendor id (assigned by IANA) [4].
Syntax:
.nf
.in 6
<!ELEMENT vendor EMPTY>
<!ATTLIST vendor
.in 12
id CDATA #REQUIRED,
name CDATA #IMPLIED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
id Required
_
name Optional
.TE
.in 0
3.1.1 vendor Attribute "id"
.in 3
The "id" attribute is the vendor code assigned by IANA [4].
.in 0
3.1.2 vendor Attribute "name"
.in 3
The "name" attribute is some text describing the vendor. It is usually
used to print out a vendor name in a human readable format.
(The Diameter protocol only transmits the vendor id)
.in 0
3.2 Type Definition Container
.in 3
The Type Definition container defines a valid diameter type. It is
assumed that the base protocol types are hard coded into the server. The
most common use of this container is to indicate which base type a derived
type derives from. This helps the server to know how (and if) an AVP should
be displayed.
Syntax:
.nf
.in 6
<!ELEMENT typedefn EMPTY>
.in 6
<!ATTLIST typedefn
.in 12
type-name ID #REQUIRED,
type-parent IDREF #IMPLIED,
description CDATA #IMPLIED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
type-name Required
_
type-parent Optional, KEY
_
description Optional
.TE
.in 0
3.2.1 typedefn Attribute "type-name"
.in 3
The attribute, "type-name" contains an ascii representation of the type.
It is an ID field so that the DTD can confirm that the "type-parent"
attribute corresponds to some already existing type.
.in 0
3.2.2 typedefn Attribute "type-parent"
.in 3
The "type-parent" attribute is required for all derived types. It MUST
correspond to the type-name of some base type.
.in 0
3.2.3 typedefn Attribute "description"
.in 3
The "description" attribute is an optional attribute describing the type.
Typically a human readable description of what the type is used for would
be included here.
.in 0
3.3 Enumerated Types Container
.in 3
Enumerated elements define values for an Enumerated AVP. You will have
one or more Enumerated containers for any AVP requiring defined values.
For example, if a particular AVP had two values, Yes and No corresponding
to 1 and 0, then the entry would looklike this:
.in 6
.nf
<enum name="Yes" code="1">
<enum name="No" code="0">
.fi
.in 3
Enumerated elements should only be used with Unsigned32 typed AVPs.
Syntax:
.nf
.in 6
<!ELEMENT enum EMPTY>
<!ATTLIST enum
.in 12
name CDATA #REQUIRED,
code CDATA #REQUIRED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
name Required
_
code Required
.TE
.in 0
3.3.1 enum Attribute "name"
.in 3
The "name" attribute is the text corresponding to a particular
value for the attribute.
.in 0
3.3.3 enum Attribute "code"
.in 3
The "code" attribute is the Unsigned32 value corresponding to this
enumerated value.
.in 0
3.4 Attribute Value Pairs
.in 3
AVPs are the most frequent container used in Dictionaries. It contains
a Type container, or a grouped container, and, possibly, some enumerations.
The AVP container completely defines one Attribute Value Pair, including
flags and format.
An AVP should only contain enumerations if the type is Unsigned32.
Syntax:
.nf
.in 6
<!ELEMENT avp (
.in 12
(type | grouped),
(enum *)>
.in 6
<!ATTLIST avp
.in 12
name ID #REQUIRED
description CDATA #IMPLIED
code CDATA #REQUIRED
may-encrypt (yes | no) "yes"
mandatory (must | may | mustnot | shouldnot) "may"
protected (must | may | mustnot | shouldnot) "may"
vendor-id CDATA #IMPLIED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
name ID Required
_
description optional
_
code Required
_
may-encrypt yes or no (default is yes)
_
mandatory must, may, mustnot,
shouldnot (default is may)
_
protected must, may, mustnot,
shouldnot (default is may)
_
vendor-id Optional
.TE
.in 0
3.4.1 avp Attribute "name"
.in 3
The "name" attribute is the mnemonic describing this attribute, for example,
"User-Name"
.in 0
3.4.2 avp Attribute "description"
.in 3
The "description" attribute is an optional attribute used to describe
the use of the AVP.
.in 0
3.4.3 avp Attribute "code"
.in 3
The "code" attribute defines the integer value used to transmit the AVP
on the network.
.in 0
3.4.4 avp Attribute "may-encrypt"
.in 3
If the "may-encrypt" attribute is "yes", then this AVP will be sent
encrypted if the connection uses CMS security.
.in 0
3.4.5 avp Attribute "mandatory"
.in 3
The "mandatory" attribute defines whether the mandatory bit of this AVP
should or should not be set.
.in 0
3.4.6 avp Attribute "protected"
.in 3
The "protected" attribute defines whether the protected bit of this AVP
should or should not be set.
.in 0
3.4.7 avp Attribute "vendor-id"
.in 3
The "vendor-id" attribute should be set to the "id" attribute of a "vendor"
element, if this is a vendor specific AVP.
.in 0
3.5 Grouped AVPs
.in 3
Grouped AVPs are used to send multiple data objects together as a
single payload. The "grouped" container defines such an object.
A "grouped" container consists of one or more "gavp" elements. Each
"gavp" container holds an avp "name" and "vendor-id". This way, a
single "grouped" container can contain references to multiple AVPs.
Syntax:
.nf
.in 6
<!ELEMENT grouped (
.in 12
gavp+)>
.in 6
<!ELEMENT gavp EMPTY>
<!ATTLIST gavp
.in 12
name IDREF #REQUIRED
vendor-id CDATA #IMPLIED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
name Required
_
vendor-id Optional
.TE
.in 0
3.5.1 gavp Attribute "name"
.in 3
The "name" attribute MUST correspond to some existing AVP's "name" attribute.
.in 0
3.5.2 gavp Attribute "vendor-id"
.in 3
If this "gavp" container reffers to a vendor specific AVP, then the "vendor-id"
attribute MUST correspond to a Vendor's "id" attribute.
.in 0
3.6 AVP Rules
.in 3
AVP rules elements define the placement of key AVPs withing commands. They
are used to do some symmantic checking at the protocol layer. For example,
a particular AVP might be required to be first in a particular message. This
container can define those rules.
Since a command might have different rules for requests and responses,
both requestrules and answerrules may be defined. Both elements must
have at least one rule if they are defined.
Syntax:
.nf
.in 6
<!ELEMENT requestrules (
.in 12
avprule+)>
.in 6
<!ELEMENT answerrules (
.in 12
avprule+)>
.in 6
<!ELEMENT avprule EMPTY>
<!ATTLIST avprule
.in 12
name IDREF #REQUIRED
position (first | last | unspecified) "unspecified"
maximum CDATA "none"
minimum CDATA "0">
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
name Required
_
position first, last, or unspecified
(default is unspecified)
_
maximum Required
_
minimum Required
.TE
.in 0
3.6.1 avprule Attribute "name"
.in 3
This rule applies to the AVP named "name".
.in 0
3.6.2 avprule Attribute "position"
.in 3
The named AVP must be either "first" in the command, "last" in the command,
or its position does not matter ("unspecified").
.in 0
3.6.3 avprule Attribute "maximum"
.in 3
The "maximum" attribute defines the maximum number of times this AVP can
occur in the command. 0 means the AVP MUST not occur in the command.
.in 0
3.6.4 avprule Attribute "minimum"
.in 3
The "minimum" attribute defines the maximum number of times this AVP can
occur in the command. 0 means the AVP is optional.
.in 0
3.7 Commands
.in 3
A command container defines the attributes for a command, and contains
any rules to be applied to it. (Note: See Section 3.6 AVP Rules)
Syntax:
.nf
.in 6
<!ELEMENT command (
.in 12
requestrules*,
answerrules*)>
.in 6
<!ATTLIST command
.in 12
name CDATA #REQUIRED
code CDATA #REQUIRED
vendor-id CDATA #IMPLIED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
name Required
_
code Required
_
vendor-id Optional
.TE
.in 0
3.7.1 command Attribute "name"
.in 3
The "name" attribute defines the name of the command. Only one command
is defined for both "Request" and "Answer" portions. So, the
"Capabilities-Exchange" command defines the messages,
"Capabilities-Exchange-Request", and "Capabilities-Exchange-Answer".
.in 0
3.7.2 command Attribute "code"
.in 3
The "code" attribute defines the command code used to transmit this
command.
.in 0
3.7.3 command Attribute "vendor-id"
.in 3
If this is a vendor specific command, then the "vendor-id" attribute MUST
correspond to a vendor container's "id" field.
.in 0
3.8 Applications and Base Protocol
.in 3
The base commands, and application specific commands have identical syntax,
with the exception that the base protocol requires at least one type, avp,
and command be defined. So, they are being described together.
Applications must define any Commands, Types, or AVPs that they define. The
application (or base) container hold those definitions.
Syntax:
.nf
.in 6
<!ELEMENT base (
.in 12
command+,
typedefn+,
avp+)>
.in 6
<!ATTLIST base
.in 12
uri CDATA #IMPLIED>
.in 6
<!ELEMENT application (
.in 12
command*,
typedefn*,
avp*)>
.in 6
<!ATTLIST application
.in 12
id CDATA #REQUIRED
name CDATA #IMPLIED
uri CDATA #IMPLIED>
.fi
.TS
box;
c|c
l|r.
Attribute Classification
=
uri Optional
_
name Optional
(application only)
_
id Required
(application only)
.TE
3.8.1 application and base Attribute "id"
.in 3
The "id" attribute is the IANA assigned Application Identifier for this
application.
.in 0
3.8.2 application and base Attribute "name"
.in 3
The "name" attribute is the human readable name of this application.
.in 0
3.8.3 application and base Attribute "uri"
.in 3
The "uri" attribute is an optional reference used to provide useful information
about this application. For example, the base protocol has a URI that
points to the most recent Diameter Base Protocol draft.
.in 0
4.0 References
.in 10
.ti -5
[1] Calhoun, P., et. al., "The DIAMETER Base Protocol," draft-ietf-
aaa-diameter-08.txt, a work in progress.
.ti -5
[2] "Extensible Markup Language (XML) 1.0" W3C Recommendation
10-February-1998 http://www.w3.org/TR/1998/REC-xml-19980210
.ti -5
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
.ti -5
[4] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700,
October 1994.
.in 0
5.0 Acknowledgments
.in 3
I'd like to thank yatta yatta yatta
.in 0
6.0 Authors' Addresses
.in 3
Questions about this memo can be directed to:
.in 6
.nf
David Frascone
Sun Microsystems, Inc.
Sun Labs
605 N. Frances Street
Terrell, Texas 75160
USA
Phone: +1 972-386-1283
Fax: +1 978-334-0249
E-mail: codemonkey [at] sun.com
Mark Jones
Bridgewater Systems
XXXXX
XXXXX
USA
Phone: +1 XXX-XXX-XXXX
Fax: +1 XXX-XXX-XXXX
E-mail: mjones [at] bridgewatersystems.com
Eric Guttman
Sun Microsystems, Inc.
XXXXX
XXX
Phone: +XXXXX
Fax: +XXXXX
E-mail: eric.guttman [at] sun.com
.fi
.bp
.in 0
Appendix A. Document Type Definition
.in 3
.DS
.so dictionary.dtd
.DE
.bp
.in 0
Appendix B. DTD & Dictionary Links
.nf
.in 3
DTD:
.in 6
http://www.diameter.org/diameter/dictionary.dtd
.in 3
dictionary:
.in 6
http://www.diameter.org/diameter/dictionary.xml
http://www.diameter.org/diameter/nasreq.xml
http://www.diameter.org/diameter/mobileipv4.xml
http://www.diameter.org/diameter/sunping.xml
.in 3
Mirror:
.in 6
DTD:
.in 9
http://diameter.frascone.com/diameter/dictionary.dtd
.in 6
dictionary:
.in 9
http://diameter.frascone.com/diameter/dictionary.xml
http://diameter.frascone.com/diameter/nasreq.xml
http://diameter.frascone.com/diameter/mobileipv4.xml
http://diameter.frascone.com/diameter/sunping.xml
.fi
AAA Working Group David Frascone
Internet-Draft Sun Microsystems, Inc.
Category: Informational Mark Jones
Bridgewater Systems
Eric Guttman
Sun Microsystems, Inc.
January 2002
Diameter XML Dictionary
<draft-ietf-aaa-xml-dictionary-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society 2002. All Rights Reserved.
Abstract
This document describes a coding Diameter dictionaries in XML. This
coding is intended for use by Diameter implementations to represent
Applications, Comands, Vendors, and AVPs.
Frascone et al. expires June 2002 [Page 1]
Internet-Draft January 2002
Discussion of this document
Send comments to the AAA Working Group mailing list <aaa-
wg [at] merit.edu>. To subscribe to the list, send a message with the
body 'subscribe aaa-wg' to <majordomo [at] merit.edu>
Table of Contents
1.0 Introduction
2.0 Specifications and Requirements
3.0 Dictionary Layout
3.1 Vendors Container
3.1.1 vendor Attribute "id"
3.1.2 vendor Attribute "name"
3.2 Type Definition Container
3.2.1 typedefn Attribute "type-name"
3.2.2 typedefn Attribute "type-parent"
3.2.3 typedefn Attribute "description"
3.3 Enumerated Types Container
3.3.1 enum Attribute "name"
3.3.3 enum Attribute "code"
3.4 Attribute Value Pairs
3.4.1 avp Attribute "name"
3.4.2 avp Attribute "description"
3.4.3 avp Attribute "code"
3.4.4 avp Attribute "may-encrypt"
3.4.5 avp Attribute "mandatory"
3.4.6 avp Attribute "protected"
3.4.7 avp Attribute "vendor-id"
3.5 Grouped AVPs
3.5.1 gavp Attribute "name"
3.5.2 gavp Attribute "vendor-id"
3.6 AVP Rules
3.6.1 avprule Attribute "name"
3.6.2 avprule Attribute "position"
3.6.3 avprule Attribute "maximum"
3.6.4 avp Attribute "minimum"
3.7 Commands
3.7.1 command Attribute "name"
3.7.2 command Attribute "code"
3.7.3 command Attribute "vendor-id"
3.8 Applications and Base Protocol
3.8.1 application and base Attribute "id"
3.8.2 application and base Attribute "name"
3.8.3 application and base Attribute "uri"
4.0 References
5.0 Acknowledgments
6.0 Authors' Addresses
Frascone et al. expires June 2002 [Page 2]
Internet-Draft January 2002
Appendix A. Document Type Definition
Appendix B. DTD & Dictionary Links
Frascone et al. expires June 2002 [Page 3]
Internet-Draft January 2002
1.0 Introduction
Diameter [1] is an extensible protocol used to provide AAA services
to different access technologies. To maintain extensibility, Diame-
ter uses a dictionary to provide it with the format of commands and
AVPs.
This document describes the representation of the Diameter dictionary
using XML [2].
2.0 Specifications and Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [3].
3.0 Dictionary Layout
The dictionary is composed of several XML files, liked together with
external entity tags. In the top level file (which SHOULD be called
"dictionary.xml"), Vendors, types, and the base protocol are defined.
Other applications SHOULD be defined in other external entity files.
Syntax:
<!ELEMENT dictionary (
vendor*,
base,
application*)>
+------------+----------------+
| Element | Classification |
+------------+----------------+
|vendor | Zero or More |
+------------+----------------+
|base | Required |
+------------+----------------+
|application | Zero or More |
+------------+----------------+
3.1 Vendors Container
The Vendor container defines a vendor, and associates it's name with
a vendor id (assigned by IANA) [4].
Syntax:
Frascone et al. expires June 2002 [Page 4]
Internet-Draft January 2002
<!ELEMENT vendor EMPTY>
<!ATTLIST vendor
id CDATA #REQUIRED,
name CDATA #IMPLIED>
+----------+----------------+
|Attribute | Classification |
+----------+----------------+
|id | Required |
+----------+----------------+
|name | Optional |
+----------+----------------+
3.1.1 vendor Attribute "id"
The "id" attribute is the vendor code assigned by IANA [4].
3.1.2 vendor Attribute "name"
The "name" attribute is some text describing the vendor. It is usu-
ally used to print out a vendor name in a human readable format.
(The Diameter protocol only transmits the vendor id)
3.2 Type Definition Container
The Type Definition container defines a valid diameter type. It is
assumed that the base protocol types are hard coded into the server.
The most common use of this container is to indicate which base type
a derived type derives from. This helps the server to know how (and
if) an AVP should be displayed.
Syntax:
<!ELEMENT typedefn EMPTY>
<!ATTLIST typedefn
type-name ID #REQUIRED,
type-parent IDREF #IMPLIED,
description CDATA #IMPLIED>
Frascone et al. expires June 2002 [Page 5]
Internet-Draft January 2002
+------------+----------------+
| Attribute | Classification |
+------------+----------------+
|type-name | Required |
+------------+----------------+
|type-parent | Optional, KEY |
+------------+----------------+
|description | Optional |
+------------+----------------+
3.2.1 typedefn Attribute "type-name"
The attribute, "type-name" contains an ascii representation of the
type. It is an ID field so that the DTD can confirm that the "type-
parent" attribute corresponds to some already existing type.
3.2.2 typedefn Attribute "type-parent"
The "type-parent" attribute is required for all derived types. It
MUST correspond to the type-name of some base type.
3.2.3 typedefn Attribute "description"
The "description" attribute is an optional attribute describing the
type. Typically a human readable description of what the type is
used for would be included here.
3.3 Enumerated Types Container
Enumerated elements define values for an Enumerated AVP. You will
have one or more Enumerated containers for any AVP requiring defined
values.
For example, if a particular AVP had two values, Yes and No corre-
sponding to 1 and 0, then the entry would looklike this:
<enum name="Yes" code="1">
<enum name="No" code="0">
Enumerated elements should only be used with Unsigned32 typed AVPs.
Syntax:
<!ELEMENT enum EMPTY>
<!ATTLIST enum
name CDATA #REQUIRED,
code CDATA #REQUIRED>
Frascone et al. expires June 2002 [Page 6]
Internet-Draft January 2002
+----------+----------------+
|Attribute | Classification |
+----------+----------------+
|name | Required |
+----------+----------------+
|code | Required |
+----------+----------------+
3.3.1 enum Attribute "name"
The "name" attribute is the text corresponding to a particular value
for the attribute.
3.3.3 enum Attribute "code"
The "code" attribute is the Unsigned32 value corresponding to this
enumerated value.
3.4 Attribute Value Pairs
AVPs are the most frequent container used in Dictionaries. It con-
tains a Type container, or a grouped container, and, possibly, some
enumerations. The AVP container completely defines one Attribute
Value Pair, including flags and format.
An AVP should only contain enumerations if the type is Unsigned32.
Syntax:
<!ELEMENT avp (
(type | grouped),
(enum *)>
<!ATTLIST avp
name ID #REQUIRED
description CDATA #IMPLIED
code CDATA #REQUIRED
may-encrypt (yes | no) "yes"
mandatory (must | may | mustnot | shouldnot) "may"
protected (must | may | mustnot | shouldnot) "may"
vendor-id CDATA #IMPLIED>
Frascone et al. expires June 2002 [Page 7]
Internet-Draft January 2002
+------------+----------------------------+
| Attribute | Classification |
+------------+----------------------------+
|name | ID Required |
+------------+----------------------------+
|description | optional |
+------------+----------------------------+
|code | Required |
+------------+----------------------------+
|may-encrypt | yes or no (default is yes) |
+------------+----------------------------+
|mandatory | must, may, mustnot, |
| | shouldnot (default is may) |
+------------+----------------------------+
|protected | must, may, mustnot, |
| | shouldnot (default is may) |
+------------+----------------------------+
|vendor-id | Optional |
+------------+----------------------------+
3.4.1 avp Attribute "name"
The "name" attribute is the mnemonic describing this attribute, for
example, "User-Name"
3.4.2 avp Attribute "description"
The "description" attribute is an optional attribute used to describe
the use of the AVP.
3.4.3 avp Attribute "code"
The "code" attribute defines the integer value used to transmit the
AVP on the network.
3.4.4 avp Attribute "may-encrypt"
If the "may-encrypt" attribute is "yes", then this AVP will be sent
encrypted if the connection uses CMS security.
3.4.5 avp Attribute "mandatory"
The "mandatory" attribute defines whether the mandatory bit of this
AVP should or should not be set.
3.4.6 avp Attribute "protected"
The "protected" attribute defines whether the protected bit of this
Frascone et al. expires June 2002 [Page 8]
Internet-Draft January 2002
AVP should or should not be set.
3.4.7 avp Attribute "vendor-id"
The "vendor-id" attribute should be set to the "id" attribute of a
"vendor" element, if this is a vendor specific AVP.
3.5 Grouped AVPs
Grouped AVPs are used to send multiple data objects together as a
single payload. The "grouped" container defines such an object.
A "grouped" container consists of one or more "gavp" elements. Each
"gavp" container holds an avp "name" and "vendor-id". This way, a
single "grouped" container can contain references to multiple AVPs.
Syntax:
<!ELEMENT grouped (
gavp+)>
<!ELEMENT gavp EMPTY>
<!ATTLIST gavp
name IDREF #REQUIRED
vendor-id CDATA #IMPLIED>
+----------+----------------+
|Attribute | Classification |
+----------+----------------+
|name | Required |
+----------+----------------+
|vendor-id | Optional |
+----------+----------------+
3.5.1 gavp Attribute "name"
The "name" attribute MUST correspond to some existing AVP's "name"
attribute.
3.5.2 gavp Attribute "vendor-id"
If this "gavp" container reffers to a vendor specific AVP, then the
"vendor-id" attribute MUST correspond to a Vendor's "id" attribute.
3.6 AVP Rules
Frascone et al. expires June 2002 [Page 9]
Internet-Draft January 2002
AVP rules elements define the placement of key AVPs withing commands.
They are used to do some symmantic checking at the protocol layer.
For example, a particular AVP might be required to be first in a par-
ticular message. This container can define those rules.
Since a command might have different rules for requests and
responses, both requestrules and answerrules may be defined. Both
elements must have at least one rule if they are defined.
Syntax:
<!ELEMENT requestrules (
avprule+)>
<!ELEMENT answerrules (
avprule+)>
<!ELEMENT avprule EMPTY>
<!ATTLIST avprule
name IDREF #REQUIRED
position (first | last | unspecified) "unspecified"
maximum CDATA "none"
minimum CDATA "0">
+----------+-----------------------------+
|Attribute | Classification |
+----------+-----------------------------+
|name | Required |
+----------+-----------------------------+
|position | first, last, or unspecified |
| | (default is unspecified) |
+----------+-----------------------------+
|maximum | Required |
+----------+-----------------------------+
|minimum | Required |
+----------+-----------------------------+
3.6.1 avprule Attribute "name"
This rule applies to the AVP named "name".
3.6.2 avprule Attribute "position"
The named AVP must be either "first" in the command, "last" in the
command, or its position does not matter ("unspecified").
3.6.3 avprule Attribute "maximum"
Frascone et al. expires June 2002 [Page 10]
Internet-Draft January 2002
The "maximum" attribute defines the maximum number of times this AVP
can occur in the command. 0 means the AVP MUST not occur in the com-
mand.
3.6.4 avprule Attribute "minimum"
The "minimum" attribute defines the maximum number of times this AVP
can occur in the command. 0 means the AVP is optional.
3.7 Commands
A command container defines the attributes for a command, and con-
tains any rules to be applied to it. (Note: See Section 3.6 AVP
Rules)
Syntax:
<!ELEMENT command (
requestrules*,
answerrules*)>
<!ATTLIST command
name CDATA #REQUIRED
code CDATA #REQUIRED
vendor-id CDATA #IMPLIED>
+----------+----------------+
|Attribute | Classification |
+----------+----------------+
|name | Required |
+----------+----------------+
|code | Required |
+----------+----------------+
|vendor-id | Optional |
+----------+----------------+
3.7.1 command Attribute "name"
The "name" attribute defines the name of the command. Only one com-
mand is defined for both "Request" and "Answer" portions. So, the
"Capabilities-Exchange" command defines the messages, "Capabilities-
Exchange-Request", and "Capabilities-Exchange-Answer".
3.7.2 command Attribute "code"
The "code" attribute defines the command code used to transmit this
Frascone et al. expires June 2002 [Page 11]
Internet-Draft January 2002
command.
3.7.3 command Attribute "vendor-id"
If this is a vendor specific command, then the "vendor-id" attribute
MUST correspond to a vendor container's "id" field.
3.8 Applications and Base Protocol
The base commands, and application specific commands have identical
syntax, with the exception that the base protocol requires at least
one type, avp, and command be defined. So, they are being described
together.
Applications must define any Commands, Types, or AVPs that they
define. The application (or base) container hold those definitions.
Syntax:
<!ELEMENT base (
command+,
typedefn+,
avp+)>
<!ATTLIST base
uri CDATA #IMPLIED>
<!ELEMENT application (
command*,
typedefn*,
avp*)>
<!ATTLIST application
id CDATA #REQUIRED
name CDATA #IMPLIED
uri CDATA #IMPLIED>
Frascone et al. expires June 2002 [Page 12]
Internet-Draft January 2002
+----------+--------------------+
|Attribute | Classification |
+----------+--------------------+
|uri | Optional |
+----------+--------------------+
|name | Optional |
| | (application only) |
+----------+--------------------+
|id | Required |
| | (application only) |
+----------+--------------------+
3.8.1 application and base Attribute "id"
The "id" attribute is the IANA assigned Application Identifier for
this application.
3.8.2 application and base Attribute "name"
The "name" attribute is the human readable name of this application.
3.8.3 application and base Attribute "uri"
The "uri" attribute is an optional reference used to provide useful
information about this application. For example, the base protocol
has a URI that points to the most recent Diameter Base Protocol
draft.
4.0 References
[1] Calhoun, P., et. al., "The DIAMETER Base Protocol," draft-
ietf- aaa-diameter-08.txt, a work in progress.
[2] "Extensible Markup Language (XML) 1.0" W3C Recommendation
10-February-1998 http://www.w3.org/TR/1998/REC-xml-19980210
[3] Bradner, S., "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, RFC 2119, March 1997.
[4] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC
1700, October 1994.
5.0 Acknowledgments
I'd like to thank yatta yatta yatta
Frascone et al. expires June 2002 [Page 13]
Internet-Draft January 2002
6.0 Authors' Addresses
Questions about this memo can be directed to:
David Frascone
Sun Microsystems, Inc.
Sun Labs
605 N. Frances Street
Terrell, Texas 75160
USA
Phone: +1 972-386-1283
Fax: +1 978-334-0249
E-mail: codemonkey [at] sun.com
Mark Jones
Bridgewater Systems
XXXXX
XXXXX
USA
Phone: +1 XXX-XXX-XXXX
Fax: +1 XXX-XXX-XXXX
E-mail: mjones [at] bridgewatersystems.com
Eric Guttman
Sun Microsystems, Inc.
XXXXX
XXX
Phone: +XXXXX
Fax: +XXXXX
E-mail: eric.guttman [at] sun.com
Frascone et al. expires June 2002 [Page 14]
Internet-Draft January 2002
Appendix A. Document Type Definition
Frascone et al. expires June 2002 [Page 15]
Internet-Draft January 2002
<?xml version="1.0" encoding="UTF-8"?>
<!--
$Log: dictionary.dtd,v $
Revision 1.6 2001/12/13 23:07:26 dave
Updated DTD and dictionary files with new changes. Please review
and send me e-mail with any comments.
Revision 1.5 2001/09/27 16:50:44 dave
Testing CVS to mailing list. Nothing changed in file.
Revision 1.4 2001/09/27 16:44:19 dave
Test for cvs
Revision 1.3 2001/09/19 21:38:57 mjones
Removed #PCDATA from command element.
Revision 1.2 2001/09/19 19:46:38 mjones
Moved the vendor element to be the same level as base and application.
Modified vendor-id to be SMI Private Enterprise Code instead of a label.
Removed vendor-id="None" since vendor-id was IMPLIED.
Added type attribute to command (request or answer).
Removed duplicate AVPs from nasreq.xml (Acct-Session-Id,
Acct-Multi-Session-Id)
Corrected typos in enum codes for Auth-Session-State and
Disconnect-Cause.
Revision 1.1 2001/08/24 18:04:44 chaos
Added per Mark's request
Revision 1.3 2001/07/31 17:43:36 chaos
Oops, forgot to turn on validity checking. Fixed some errors found
with validity checking turned on
Revision 1.2 2001/07/31 16:56:15 chaos
Lots of changes to support flags like in the draft, and to support
commands
-->
<!ELEMENT dictionary (vendor*, base, application*)>
<!ELEMENT vendor EMPTY>
<!ATTLIST vendor
id CDATA #REQUIRED
name CDATA #IMPLIED
>
<!ELEMENT base (command*, typedefn+, avp+)>
<!ATTLIST base
uri CDATA #IMPLIED
>
<!ELEMENT application (command*, typedefn*, avp*)>
Frascone et al. expires June 2002 [Page 16]
Internet-Draft January 2002
<!ATTLIST application
id CDATA #REQUIRED
name CDATA #IMPLIED
uri CDATA #IMPLIED
>
<!ELEMENT command (requestrules*, answerrules*)>
<!ATTLIST command
name CDATA #REQUIRED
code CDATA #REQUIRED
vendor-id CDATA #IMPLIED
>
<!ELEMENT typedefn EMPTY>
<!ATTLIST typedefn
type-name ID #REQUIRED
type-parent IDREF #IMPLIED
description CDATA #IMPLIED
>
<!ELEMENT avp ((type | grouped), (enum*))>
<!ATTLIST avp
name ID #REQUIRED
description CDATA #IMPLIED
code CDATA #REQUIRED
may-encrypt (yes | no) "yes"
mandatory (must | may | mustnot | shouldnot) "may"
protected (must | may | mustnot | shouldnot) "may"
vendor-id CDATA #IMPLIED
>
<!ELEMENT type EMPTY>
<!ATTLIST type
type-name IDREF #REQUIRED
>
<!ELEMENT grouped (gavp+)>
<!ELEMENT gavp EMPTY>
<!ATTLIST gavp
name IDREF #REQUIRED
vendor-id CDATA #IMPLIED
>
<!ELEMENT enum EMPTY>
<!ATTLIST enum
name CDATA #REQUIRED
code CDATA #REQUIRED
>
<!ELEMENT requestrules (avprule+)>
<!ELEMENT answerrules (avprule+)>
<!ELEMENT avprule EMPTY>
Frascone et al. expires June 2002 [Page 17]
Internet-Draft January 2002
<!ATTLIST avprule
name IDREF #REQUIRED
position (first | last | unspecified) "unspecified"
maximum CDATA "none"
minimum CDATA "0"
>
Frascone et al. expires June 2002 [Page 18]
Internet-Draft January 2002
Appendix B. DTD & Dictionary Links
DTD:
http://www.diameter.org/diameter/dictionary.dtd
dictionary:
http://www.diameter.org/diameter/dictionary.xml
http://www.diameter.org/diameter/nasreq.xml
http://www.diameter.org/diameter/mobileipv4.xml
http://www.diameter.org/diameter/sunping.xml
Mirror:
DTD:
http://diameter.frascone.com/diameter/dictionary.dtd
dictionary:
http://diameter.frascone.com/diameter/dictionary.xml
http://diameter.frascone.com/diameter/nasreq.xml
http://diameter.frascone.com/diameter/mobileipv4.xml
http://diameter.frascone.com/diameter/sunping.xml
Frascone et al. expires June 2002 [Page 19]
Attachment:
draft-ietf-aaa-xml-dictionary-00.pdf
Description: Adobe PDF document
-
It's input time guys. David Frascone, January 28 2002
-
RE: It's input time guys. Mark Jones, January 28 2002
- Re: It's input time guys. David Frascone, January 28 2002
-
RE: It's input time guys. Mark Jones, January 31 2002
- Re: It's input time guys. David Frascone, January 31 2002
-
RE: It's input time guys. Mark Jones, January 28 2002
Results generated by Tiger Technologies using MHonArc.