Update to the ipn URI scheme
draft-taylor-dtn-ipn-update-03
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Rick Taylor , Edward J. Birrane | ||
| Last updated | 2022-10-21 | ||
| Replaced by | draft-ietf-dtn-ipn-update | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-dtn-ipn-update | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The 'ipn' URI scheme was first defined in [RFC6260] as a format for endpoint identifiers with the Delay Tolerant Networking Bundle Protocol version 6 (BPv6) [RFC5050], when using Compressed Bundle Header Encoding (CBHE). [RFC7116] requested IANA registries to control the allocation of the numeric identifiers used with the 'ipn' URI scheme. The Bundle Protocol version 7 (BPv7) specification [RFC9171] repeats the definition of the 'ipn' URI scheme, for use with BPv7, reusing the format from [RFC6260]. Because the specification of the 'ipn' URI scheme has been split over several documents, referencing different versions of the Bundle Protocol, some confusion has occurred amongst readers and implementers. This document pulls together the information contained in those previous documents and asserts the specification of the 'ipn' URI scheme for use with BPv7, acting as an update to those previous documents. A criticism of the existing 'ipn' URI scheme node number allocation strategy as defined in [RFC7116] is that sub-ranges of a single number space are assigned for the use by individual organisations. This allocation strategy results in inefficient encoding of URIs with BPv7. This document extends the format of the 'ipn' URI scheme to include Numbering Authorities, allowing for a more flexible sub- allocation strategy, resulting in a more efficient encoding with BPv7.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)