1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
ACAP NUMBERS
(last updated 2001 June 25)
Registration Procedures
ACAP's usefulness comes from providing a structured storage model for
all sorts of configuration data. However, for its potential to be
achieved, it is important that the Internet community strives for the
following goals:
(1) Standardization. It is very important to standardize dataset
classes. The authors hope that ACAP achieves the success that SNMP
has seen with the definition of numerous standards track MIBs.
(2) Community Review. In the absence of standardization, it is
important to get community review on a proposal to improve its
engineering quality. Community review is strongly recommended
prior to registration. The ACAP implementors mailing list
<ietf-acap@andrew.cmu.edu> should be used for this purpose.
(3) Registration. Registration serves a two-fold purpose. First
it prevents use of the same name for different purposes, and second
it provides a one-stop list which can be used to locate existing
extensions or dataset classes to prevent duplicate work.
The following registration templates may be used to register ACAP
protocol elements with the Internet Assigned Numbers Authority
(IANA).
7.1. ACAP Capabilities
New ACAP capabilities MUST be registered prior to use. Careful
consideration should be made before extending the protocol, as it can
lead to complexity or interoperability problems. Review of proposals
on the acap implementors mailing list is strongly encouraged prior
toregistration.
To: iana@iana.org
Subject: Registration of ACAP capability
Capability name:
Capability keyword:
Capability arguments:
Published Specification(s):
(Optional, but strongly encouraged)
Person and email address to contact for further information:
7.2. ACAP Response Codes
ACAP response codes are registered on a first come, first served
basis. Review of proposals on the acap implementors mailing list
is strongly encouraged prior to registration.
To: iana@iana.org
Subject: Registration of ACAP response code
Response Code:
Arguments (use ABNF to specify syntax):
Purpose:
Published Specification(s):
(Optional, but strongly encouraged)
Person and email address to contact for further information:
7.3. Dataset Classes
A dataset class provides a core set of attributes for use in a
specified hierarchy. It may also define rules for the dataset
hierarchy underneath that class. Dataset class specifications must
be standards track or IESG approved experimental RFCs.
To: iana@iana.org
Subject: Registration of ACAP dataset class
Dataset class name/attribute prefix:
Purpose:
Published Specification(s):
(Standards track or IESG approved experimental RFC)
Person and email address to contact for further information:
7.4. Vendor Subtree
Vendors may reserve a portion of the ACAP namespace for private use.
Dataset class names beginning with "vendor.<company/product name>."
are reserved for use by that company or product. In addition, all
attribute names beginning with "vendor.<company/product name>." are
reserved for use by that company or product once registered.
Registration is on a first come, first served basis. Whenever
possible, private attributes and dataset classes should be avoided
in favor of improving interoperable dataset class definitions.
To: iana@iana.org
Subject: Registration of ACAP vendor subtree
Private Prefix: vendor.<company/product name>.
Person and email address to contact for further information:
(company names and addresses should be included when appropriate)
REGISTRATIONS
--------------------------------------------------------------------
ACAP Capabilities
Name Reference
---- ---------
STARTTLS [RFC2595]
--------------------------------------------------------------------
ACAP Response Codes
Name Reference
---- ---------
--------------------------------------------------------------------
Dataset Classes
Name Reference
---- ---------
--------------------------------------------------------------------
Vendor Subtrees
Name Reference
---- ---------
vendor.Qualcomm/Eudora [Gellens]
vendor.Eudora [Gellens]
vendor.ruslan [Shibayev]
vendor.Cyrusoft/Mulberry [Daboo]
vendor.Cyrusoft/SilkyMail [Daboo]
vendor.corvu [Rollo]
REFERENCES
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
Innosoft, June 1999.
PEOPLE
[Daboo] Cyrus Daboo, <daboo@cyrusoft.com>, June 2000.
[Gellens] Randall Gellens, <randy@qualcomm.com>, June 1998.
[Rollo] Troy Rollo, <troy@corvu.com.au>, June 2001.
[Shibayev] Dmitry Shibayev, <dmitry@ruslan-com.ru>, April 1999.
[]
|
