Hi folks, Monday (13 November 2000)
I have just discovered that the 'ipp:' URL scheme was never registered
with IANA. Bob Herriot and I plan to write an Internet-Draft which
conforms to RFC 2717. Each IANA registered URL scheme MUST be published
in a 'standards track' RFC.
The IPP/1.1 Protocol (RFC 2910) and the 'indp:' notification delivery
method I-D do NOT meet the RFC 2717 requirements.
The RFCs about URL scheme registration:
2717 Registration Procedures for URL Scheme Names. R. Petke, I. King.
November 1999. (Format: TXT=19780 bytes) (Also BCP0035) (Status:
BEST CURRENT PRACTICE)
2718 Guidelines for new URL Schemes. L. Masinter, H. Alvestrand, D.
Zigmond, R. Petke. November 1999. (Format: TXT=19208 bytes)
(Status: INFORMATIONAL)
A recent RFC that conforms to RFC 2717 (and was registered):
2806 URLs for Telephone Calls. A. Vaha-Sipila. April 2000. (Format:
TXT=50647 bytes) (Status: PROPOSED STANDARD)
The IANA registry of URL schemes:
ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes
Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
High North Inc
------------------------------------------------------------------------
[excerpts from RFC 2717]
3.2 The IETF Tree
Registration in the IETF tree requires publication of the URL scheme
syntax and semantics in either an Informational or Standards Track
>> RFC. In general, the creation of a new URL scheme requires a
>> Standards Track RFC. An Informational RFC may be employed for
>> registration only in the case of a URL scheme which is already in
>> wide usage and meets other standards set forth in RFC 2718, such as
>> "demonstrated utility" within the Internet Architecture; the IESG
shall have broad discretion in determining whether an Informational
RFC is suitable in any given case, and may either recommend changes
to such document prior to publication, or reject it for publication.
An Informational RFC purporting to describe a URL scheme shall not be
published without IESG approval. This is a departure from practice
for Informational RFCs as set forth in RFC 2026, for the purpose of
ensuring that the registration of URL schemes shall serve the best
interests of the Internet community.
The NAMES of schemes registered in the IETF tree MUST NOT contain the
dash (also known as the hyphen and minus sign) character ('-')
USASCII value 2Dh. Use of this character can cause confusion with
schemes registered in alternative trees (see section 3.3).
>> An analysis of the security issues inherent in the new URL scheme is
>> REQUIRED. (This is in accordance with the basic requirements for all
>> IETF protocols.) URL schemes registered in the IETF tree should not
>> introduce additional security risks into the Internet Architecture.
For example, URLs should not embed information which should remain
confidential, such as passwords, nor should new schemes subvert the
security of existing schemes or protocols (i.e. by layering or
tunneling).
The "owner" of a URL scheme name registered in the IETF tree is
assumed to be the IETF itself. Modification or alteration of the
specification requires the same level of processing (e.g.
Informational or Standards Track RFC) as used for the initial
registration. Schemes originally defined via an Informational RFC
may, however, be replaced with Standards Track documents.
6.0 Registration Template
The following issues should be addressed when documenting a new URL
scheme:
URL scheme name.
>> URL scheme syntax. This should be expressed in a clear and
>> concise manner. The use of ABNF is encouraged. Please refer to
>> RFC 2718 for guidance on designing and explaining your scheme's
>> syntax.
Character encoding considerations. It is important to identify
what your scheme supports in this regard. It is obvious that for
interoperability, it is best if there is a means to support
character sets beyond USASCII, but especially for private schemes,
this may not be the case.
Intended usage. What sort of resource is being identified? If
this is not a 'resource' type of URL (e.g. mailto:), explain the
action that should be initiated by the consumer of the URL. If
there is a MIME type associated with this resource, please
identify it.
Applications and/or protocols which use this URL scheme name.
Including references to documentation which defines the
applications and/or protocols cited is especially useful.
Interoperability considerations. If you are aware of any details
regarding your scheme which might impact interoperability, please
identify them here. For example: proprietary or uncommon encoding
method; inability to support multibyte character sets;
incompatibility with types or versions of underlying protocol (if
scheme is tunneled over another protocol).
Security considerations.
Relevant publications.
Person & email address to contact for further information.
Author/Change controller.
Applications and/or protocols which use this URL scheme name.
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 documentation, so
that users are not misled as to the true security properties of a
registered URL scheme.
------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Nov 13 2000 - 17:32:05 EST