On Sat, 31 Mar 2007, Geoff Huston wrote:
Perhaps you could refer me to the process document where this is described?
http://www.iana.org/assignments/uri-schemes.html
All "permanent" URI schemes are defined protocol RFCs. Provisional schemes
are internet drafts. Procedure defined by RFC4395:
http://www.rfc-editor.org/rfc/rfc4395.txt
IANA lists URI registration as not through "expert" review with Graham
Klyne designated as expert. A quite from RFC with more details is below:
-------------
5.2. Registration Procedures
Someone wishing to register a URI scheme SHOULD:
1. Check the IANA URI scheme registry to see whether or not there is
already an entry for the desired name. If there is already an
entry under the name, choose a different URI scheme name.
2. Prepare a URI scheme registration template, as specified in
Section 5.4. The URI scheme registration template may be
contained in an Internet Draft, alone or as part of some other
protocol specification. The template may also be submitted in
some other form (as part of another document or as a stand-alone
document), but the contents will be treated as an "IETF
Contribution" under the guidelines of RFC 3978 [4].
3. Send a copy of the template or a pointer to the containing
document (with specific reference to the section with the
template) to the mailing list [EMAIL PROTECTED], requesting
review. In addition, request review on other mailing lists as
appropriate. For example, general discussion of URI syntactical
issues could be discussed on [EMAIL PROTECTED]; schemes for a network
protocol could be discussed on a mailing list for that protocol.
Allow a reasonable time for discussion and comments. Four weeks
is reasonable for a permanent registration requests.
-------------
http://www.ietf.org/rfc/rfc2026.txt
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
specifications from other standards bodies. (See Section 7.)
...
7.1.2 Incorporation of Other Specifications
Other proprietary specifications may be incorporated by reference to
a version of the specification as long as the proprietor meets the
requirements of section 10. If the other proprietary specification
is not widely and readily available, the IESG may request that it be
published as an Informational RFC.
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt
An RFC must include separate lists of normative and informative
references (see Section 4.7f below.) The distinction between
normative and informative references is often important. The IETF
standards process and the RFC Editor publication process need to
know whether a reference to a work in progress is normative. A
standards-track RFC cannot be published until all of the documents
that it lists as normative references have been published. In
practice, this often results in the simultaneous publication of a
group of interrelated RFCs.
2.8 URLs and DNS names in RFCs
The use of URLs in RFCs is discouraged, because many URLs are not
stable references. Exceptions may be made for normative
references in those cases where the URL is demonstrably the most
stable reference available. References to long-lived files on
ietf.org and rfc-editor.org are generally acceptable.
-------------
Unless I'm mistaken no document other then one published by another
standards body (i.e. W3) has ever been incorporated as normative
reference STD RFC published within last few years. But since you're
the one who collects all the docs at pataroo.net I'd expect you to
know that better.
--
William Leibzon
Elan Networks
[EMAIL PROTECTED]
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
