2004/id/draft-ietf-urlreg-procedures-00.txt

INTERNET-DRAFT                                               Rich Petke
<draft-ietf-urlreg-procedures-00.txt>       CompuServe Network Services
                                                         March 13, 1998


             Registration Procedures for URL Scheme Names


Status of this Memo

   This document is an Internet-Draft. 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."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet Draft expires September 13, 1998.


Abstract

   This document defines the process by which new URL schemes are
   registered.


1.0 Introduction

   A Uniform Resource Locator (URL) is a compact string representation
   of the location for a resource that is available via the Internet.
   RFC [URI-SYNTAX] defines the general syntax and semantics of URIs,
   and, by inclusion, URLs.  URLs are designated by including a
   "scheme" and then a "scheme-specific part".  Many URL schemes are
   already defined.

   RFC [URL-GUIDELINES] provides guidelines for the definition of new
   URL schemes, for consideration by those who are defining and
   registering or evaluating those definitions.


2.0 Scope

   The URL scheme registration process is restricted to the
   registration of new URL scheme names.


3.0 Classifications of Scheme Names

   Not all URL scheme names are created equal.  This section defines
   the various classifications for URL scheme names.  Section 4 of this
   document defines the registration procedures to be followed to
   register a scheme name.


3.1 Class 1 - Common Names

   If the name proposed for a new URL scheme is a common word,
   meaningful to a large and/or wide population, then the scheme name
   is considered a Class 1 name.  Examples of such names include:

      Telephone
      Phone
      Fax
      TV
      Weather
      Music


3.2 Class 2 - Acronyms

   Short acronyms for technical terms which do not themselves create
   common words (i.e. the acronym is not a Class 1 name), are
   considered to be Class 2 scheme names.  Examples of such names
   include:

      HTTP
      FTP
      NNTP
      TELNET
      WAIS


3.3 Class 3 - Vanity Names and Registered Trade Names

   Scheme names that echo registered trade names and vanity names are
   considered to be Class 3 scheme names.  Examples of such names
   include:

      AOL
      RealAudio
      STTNG


3.4 Class 4 - Private Schemes

   Scheme names based on IANA assigned domain names and matching the
   syntax specified below are considered to be Class 4 scheme names.

   The syntax of a class 4 URL scheme name is:

      "NOREG+" <domain>  [ "+" <extension>] ":"

   where -

      <domain> is defined in  [STD13], section 3.5.

      <extension> is optional and may contain any legal scheme name
      characters as defined in RFC [URI-SYNTAX].

   Examples of valid Class 4 URL scheme names include:

      noreg+compuserve.net+rpa:
      noreg+nt.microsoft.com:


4.0 Registration Procedures (to be followed by a requestor)

   To register a new URL scheme name:

   1. Determine which scheme name class (as described in section 3)
      best describes the proposed URL scheme name.  If the proposed
      scheme name does not appear to clearly belong to any one
      classification, request the IESG to classify the scheme name.

   2. Complete the URL scheme name registration form found in appendix
      A of this document.

   3. For Class 4 URL scheme names ONLY, forward the completed form to
      IANA directly.

   4. For all other URL scheme name classes, forward the completed form
      to the IESG.

   With the exception of Class 4 URL scheme names, which are easily
   recognizable, the IESG has the right to reclassify any proposed URL
   scheme names that have been incorrectly classified.

   The IESG should process applications for the registration of new URL
   scheme names in a timely manner.  It may delay the approval of any
   application for just cause, such as lack of consensus within the
   IETF (when a Class 1 scheme name registration is requested), or
   multiple parties attempting to register the same or similar scheme
   names.


5.0 Registration Procedures (to be followed by the IESG)

5.1 Class 1 Procedures (Common Names)

   Registering a Class 1 URL scheme name requires the consensus of the
   IETF.  The IESG will seek input on the prospective new URL scheme
   name and will either approve or reject the registration on behalf of
   the IETF.

   The IESG may require the proposed scheme to be documented in an RFC
   (standards track, informational, or BCP).

   If the IESG approves the registration, it will forward the
   registration form to IANA for recording.


5.2 Class 2 Procedures (Acronyms)

   Registering a Class 2 URL scheme name requires only the consensus of
   the IESG.  The IESG must require the proposed scheme to be
   documented in an RFC or other permanent and readily available
   reference, in sufficient detail so that interoperability between
   independent implementations is possible.

   If the IESG approves the registration and supporting documentation,
   it will forward the registration form to IANA for recording.


5.3 Class 3 Procedures (Vanity Names and Registered Trade Names)

   Class 3 URL scheme names are approved on a first come, first served
   basis.  The IESG will verify that the requested URL scheme name is
   indeed a class 3 name, that the party requesting the scheme name
   indeed has reasonable rights to register the scheme name, and that
   sufficiently stable "point of contact" information has been supplied
   in the registration form.  After verification, the IESG will forward
   the application to IANA for recording.

   The IESG may require the scheme to be documented in an RFC.


6.0 Registration Procedures (to be followed by IANA)

6.1 Procedures for Class 1, 2, and 3 URL Scheme Names

   IANA will only accept completed URL scheme name registration forms
   which have been approved by the IESG for recording.

6.2 Class 4 Procedures (Private Schemes)

   Upon receipt of a completed URL scheme name registration form, IANA
   shall:

   1. Verify that the proposed URL scheme name conforms to the syntax
      specified for Class 4 URL scheme names in section 3.4 of this
      document.
   2. Verify that the requestor is affiliated with the owner of the DNS
      name specified in the registration form.
   3. Verify that the "point of contact" information is sufficiently
      stable.
   4. Record the registration.


7.0 Security Considerations

   Information that creates or updates a registration needs to be
   authenticated.

   Information concerning possible security vulnerabilities of a
   protocol may change over time.  Consequently, claims as to the
   security properties of a registered URL scheme may change as well.
   As new vulnerabilities are discovered, information about such
   vulnerabilities may need to be attached to existing registrations,
   so that users are not misled as to the true security properties of
   a registered URL schemes.

   Delegations of a name space should only be assigned to someone with
   adequate security.


8.0 References

   [STD 13]

   [RFC-URI-SYNTAX]

   [RFC-URL-GUIDELINES]


9.0 Author's Address

   Rich Petke
   CompuServe Network Services Inc.  (WorldCom)
   5000 Britton Road
   P. O. Box 5000
   Hilliard, OH 43026-5000
   Phone: 614-723-4157
   Email: rpetke@compuserve.net


Appendix A

   URL Scheme Name Registration Form


   URL Scheme Name to be Registered (case insensitive):

   URL Scheme Name Class (1, 2, 3, 4, or unknown):

   Person Requesting Registration (name, title, affiliation, postal
   address, telephone numbers, email address):

   Point of Contact for this Registration (name, title, affiliation,
   postal address, telephone numbers, email address):

   Published specification(s) for this Scheme Name (I-Ds, RFCs, etc.):

   Other Relevant Information Regarding this Application:


   For Class 4 URL scheme names ONLY, send this form to:
   ietf-types@iana.org

   For all other URL scheme name classes, including URL scheme names of
   an unknown class, send this form to:  iesg@ietf.org.

1	INTERNET-DRAFT Rich Petke
2	<draft-ietf-urlreg-procedures-00.txt> CompuServe Network Services
3	March 13, 1998
4
5
6
7	Registration Procedures for URL Scheme Names
8
9
10
11	Status of this Memo
12
13	This document is an Internet-Draft. Internet-Drafts are working
14	documents of the Internet Engineering Task Force (IETF), its areas,
15	and its working groups. Note that other groups may also distribute
16	working documents as Internet-Drafts.
17
18	Internet-Drafts are draft documents valid for a maximum of six
19	months and may be updated, replaced, or obsoleted by other documents
20	at any time. It is inappropriate to use Internet-Drafts as
21	reference material or to cite them other than as "work in progress."
22
23	To learn the current status of any Internet-Draft, please check the
24	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
25	Directories on ds.internic.net (US East Coast), nic.nordu.net
26	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
27	Rim).
28
29	Distribution of this memo is unlimited.
30
31	This Internet Draft expires September 13, 1998.
32
33
34	Abstract
35
36	This document defines the process by which new URL schemes are
37	registered.
38
39
40	1.0 Introduction
41
42	A Uniform Resource Locator (URL) is a compact string representation
43	of the location for a resource that is available via the Internet.
44	RFC [URI-SYNTAX] defines the general syntax and semantics of URIs,
45	and, by inclusion, URLs. URLs are designated by including a
46	"scheme" and then a "scheme-specific part". Many URL schemes are
47	already defined.
48
49	RFC [URL-GUIDELINES] provides guidelines for the definition of new
50	URL schemes, for consideration by those who are defining and
51	registering or evaluating those definitions.
52
53
54	2.0 Scope
55
56	The URL scheme registration process is restricted to the
57	registration of new URL scheme names.
58
59
60	3.0 Classifications of Scheme Names
61
62	Not all URL scheme names are created equal. This section defines
63	the various classifications for URL scheme names. Section 4 of this
64	document defines the registration procedures to be followed to
65	register a scheme name.
66
67
68	3.1 Class 1 - Common Names
69
70	If the name proposed for a new URL scheme is a common word,
71	meaningful to a large and/or wide population, then the scheme name
72	is considered a Class 1 name. Examples of such names include:
73
74	Telephone
75	Phone
76	Fax
77	TV
78	Weather
79	Music
80
81
82	3.2 Class 2 - Acronyms
83
84	Short acronyms for technical terms which do not themselves create
85	common words (i.e. the acronym is not a Class 1 name), are
86	considered to be Class 2 scheme names. Examples of such names
87	include:
88
89	HTTP
90	FTP
91	NNTP
92	TELNET
93	WAIS
94
95
96	3.3 Class 3 - Vanity Names and Registered Trade Names
97
98	Scheme names that echo registered trade names and vanity names are
99	considered to be Class 3 scheme names. Examples of such names
100	include:
101
102	AOL
103	RealAudio
104	STTNG
105
106
107	3.4 Class 4 - Private Schemes
108
109	Scheme names based on IANA assigned domain names and matching the
110	syntax specified below are considered to be Class 4 scheme names.
111
112	The syntax of a class 4 URL scheme name is:
113
114	"NOREG+" <domain> [ "+" <extension>] ":"
115
116	where -
117
118	<domain> is defined in [STD13], section 3.5.
119
120	<extension> is optional and may contain any legal scheme name
121	characters as defined in RFC [URI-SYNTAX].
122
123	Examples of valid Class 4 URL scheme names include:
124
125	noreg+compuserve.net+rpa:
126	noreg+nt.microsoft.com:
127
128
129	4.0 Registration Procedures (to be followed by a requestor)
130
131	To register a new URL scheme name:
132
133	1. Determine which scheme name class (as described in section 3)
134	best describes the proposed URL scheme name. If the proposed
135	scheme name does not appear to clearly belong to any one
136	classification, request the IESG to classify the scheme name.
137
138	2. Complete the URL scheme name registration form found in appendix
139	A of this document.
140
141	3. For Class 4 URL scheme names ONLY, forward the completed form to
142	IANA directly.
143
144	4. For all other URL scheme name classes, forward the completed form
145	to the IESG.
146
147	With the exception of Class 4 URL scheme names, which are easily
148	recognizable, the IESG has the right to reclassify any proposed URL
149	scheme names that have been incorrectly classified.
150
151	The IESG should process applications for the registration of new URL
152	scheme names in a timely manner. It may delay the approval of any
153	application for just cause, such as lack of consensus within the
154	IETF (when a Class 1 scheme name registration is requested), or
155	multiple parties attempting to register the same or similar scheme
156	names.
157
158
159	5.0 Registration Procedures (to be followed by the IESG)
160
161	5.1 Class 1 Procedures (Common Names)
162
163	Registering a Class 1 URL scheme name requires the consensus of the
164	IETF. The IESG will seek input on the prospective new URL scheme
165	name and will either approve or reject the registration on behalf of
166	the IETF.
167
168	The IESG may require the proposed scheme to be documented in an RFC
169	(standards track, informational, or BCP).
170
171	If the IESG approves the registration, it will forward the
172	registration form to IANA for recording.
173
174
175	5.2 Class 2 Procedures (Acronyms)
176
177	Registering a Class 2 URL scheme name requires only the consensus of
178	the IESG. The IESG must require the proposed scheme to be
179	documented in an RFC or other permanent and readily available
180	reference, in sufficient detail so that interoperability between
181	independent implementations is possible.
182
183	If the IESG approves the registration and supporting documentation,
184	it will forward the registration form to IANA for recording.
185
186
187	5.3 Class 3 Procedures (Vanity Names and Registered Trade Names)
188
189	Class 3 URL scheme names are approved on a first come, first served
190	basis. The IESG will verify that the requested URL scheme name is
191	indeed a class 3 name, that the party requesting the scheme name
192	indeed has reasonable rights to register the scheme name, and that
193	sufficiently stable "point of contact" information has been supplied
194	in the registration form. After verification, the IESG will forward
195	the application to IANA for recording.
196
197	The IESG may require the scheme to be documented in an RFC.
198
199
200	6.0 Registration Procedures (to be followed by IANA)
201
202	6.1 Procedures for Class 1, 2, and 3 URL Scheme Names
203
204	IANA will only accept completed URL scheme name registration forms
205	which have been approved by the IESG for recording.
206
207	6.2 Class 4 Procedures (Private Schemes)
208
209	Upon receipt of a completed URL scheme name registration form, IANA
210	shall:
211
212	1. Verify that the proposed URL scheme name conforms to the syntax
213	specified for Class 4 URL scheme names in section 3.4 of this
214	document.
215	2. Verify that the requestor is affiliated with the owner of the DNS
216	name specified in the registration form.
217	3. Verify that the "point of contact" information is sufficiently
218	stable.
219	4. Record the registration.
220
221
222	7.0 Security Considerations
223
224	Information that creates or updates a registration needs to be
225	authenticated.
226
227	Information concerning possible security vulnerabilities of a
228	protocol may change over time. Consequently, claims as to the
229	security properties of a registered URL scheme may change as well.
230	As new vulnerabilities are discovered, information about such
231	vulnerabilities may need to be attached to existing registrations,
232	so that users are not misled as to the true security properties of
233	a registered URL schemes.
234
235	Delegations of a name space should only be assigned to someone with
236	adequate security.
237
238
239	8.0 References
240
241	[STD 13]
242
243	[RFC-URI-SYNTAX]
244
245	[RFC-URL-GUIDELINES]
246
247
248	9.0 Author's Address
249
250	Rich Petke
251	CompuServe Network Services Inc. (WorldCom)
252	5000 Britton Road
253	P. O. Box 5000
254	Hilliard, OH 43026-5000
255	Phone: 614-723-4157
256	Email: rpetke@compuserve.net
257
258
259	Appendix A
260
261	URL Scheme Name Registration Form
262
263
264	URL Scheme Name to be Registered (case insensitive):
265
266	URL Scheme Name Class (1, 2, 3, 4, or unknown):
267
268	Person Requesting Registration (name, title, affiliation, postal
269	address, telephone numbers, email address):
270
271	Point of Contact for this Registration (name, title, affiliation,
272	postal address, telephone numbers, email address):
273
274	Published specification(s) for this Scheme Name (I-Ds, RFCs, etc.):
275
276	Other Relevant Information Regarding this Application:
277
278
279
280
281
282
283	For Class 4 URL scheme names ONLY, send this form to:
284	ietf-types@iana.org
285
286	For all other URL scheme name classes, including URL scheme names of
287	an unknown class, send this form to: iesg@ietf.org.
288