• Aucun résultat trouvé

Abstract RFC 2648 defines the "ietf&#34

N/A
N/A
Protected

Academic year: 2022

Partager "Abstract RFC 2648 defines the "ietf&#34"

Copied!
4
0
0

Texte intégral

(1)

Internet Engineering Task Force (IETF) B. Leiba Request for Comments: 6924 Huawei Technologies Updates: 2648 April 2013 Category: Informational

ISSN: 2070-1721

Registration of Second-Level URN Namespaces under "ietf"

Abstract

RFC 2648 defines the "ietf" URN namespace and a number of sub-

namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of

"ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub-

namespaces of "ietf".

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at

http://www.rfc-editor.org/info/rfc6924.

Leiba Informational [Page 1]

(2)

RFC 6924 IETF URN Namespace Registry April 2013

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

"A URN Namespace for IETF Documents" [RFC2648] defines the "ietf" URN namespace and a number of sub-namespaces. "An IETF URN Sub-namespace for Registered Protocol Parameters" [RFC3553] defines an additional sub-namespace, "params", and creates a registry to document

allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub-namespaces of "ietf".

2. IANA Considerations

There is currently a top-level registry group called "IETF Protocol Parameter Identifiers", which contains one registry, "IETF URN Sub- namespace for Registered Protocol Parameters". IANA has taken the following three actions:

Action 1: Renamed the group "IETF Protocol Parameter Identifiers", giving it the new name "Uniform Resource Name (URN) Namespace for IETF Use". The existing registry in that group remains, and its name is unchanged. Its registration procedure has been updated to "IETF Review" (formerly called "IETF Consensus").

Action 2: Added a new registry to the renamed group. The new

registry is called "IETF URN Sub-namespaces", and new registrations will use the IETF Review policy [RFC5226], which provides for IETF consensus in order to add a new URN namespace under "ietf". The new registry appears first in the group, to provide a human-friendly, top-down resolution of the namespace hierarchy.

Leiba Informational [Page 2]

(3)

RFC 6924 IETF URN Namespace Registry April 2013

Action 3: Populated the new registry as follows:

IETF URN Sub-namespaces

Registration Procedures: IETF Review Reference: [RFC6924]

Note: This is the Official Registry for sub-namespaces of the ’IETF’

URN Namespace.

Sub-namespace | Reference | IANA Registry Reference

---+---+--- rfc | [RFC2648] | none

fyi | [RFC2648] | none std | [RFC2648] | none bcp | [RFC2648] | none id | [RFC2648] | none mtg | [RFC2648] | none

params | [RFC3553] | [http://www.iana.org/assignments/params]

---+---+--- 3. Security Considerations

This is a procedural document and is entirely unrelated to security.

4. Acknowledgments

Alfred Hoenes noticed the absence of this registry and suggested its creation.

5. References

5.1. Normative References

[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

5.2. Informative References

[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol

Parameters", BCP 73, RFC 3553, June 2003.

Leiba Informational [Page 3]

(4)

RFC 6924 IETF URN Namespace Registry April 2013

Author’s Address Barry Leiba

Huawei Technologies Phone: +1 646 827 0648

EMail: barryleiba@computer.org

URI: http://internetmessagingtechnology.org/

Leiba Informational [Page 4]

Références

Documents relatifs

They allow to group together several "m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams)

Taking account of this information, the receiving user agent (UA) can make decisions that improve message presentation for the user in the context the sender and

There are three types of name resolution services that should be provided in case B: local IPv6 capable hosts must be able to obtain the IPv6 addresses of correspondent hosts

WHOIS is a TCP-based transaction-oriented query/response protocol that is widely used to provide information services to Internet users.. While originally used to

This includes DES for encryption, MD5 and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with

The "info" Registry supports the declaration of public namespaces that are not part of the URI allocation in a manner that facilitates the construction of URIs

The compressed mode of NETRJS uses an adaptation of the particular compression scheme which is incorporated in the "Multileaving protocol" of the binary synchronous

If the "tel" URI contains the "cic" parameter whose CIC value is different from the one this network node is associated with, this network node MUST NOT