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	wakaba	1.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