RFC 9364: DNS Security Extensions (DNSSEC)

RFC 9364
DNS Security Extensions (DNSSEC)
Abstract
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are
specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce
all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This
document does not update any of those RFCs. A second purpose is to state that using DNSSEC for
origin authentication of DNS data is the best current practice. A third purpose is to provide a
single reference for other documents that want to refer to DNSSEC.
Stream:
RFC:
BCP:
Category:
Published:
ISSN:
Author:
Internet Engineering Task Force (IETF)
9364
237
Best Current Practice
February 2023
2070-1721
 P. Hoffman
ICANN
Status of This Memo
This memo documents an Internet Best Current Practice.
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). Further information on BCPs is
available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback
on it may be obtained at .https://www.rfc-editor.org/info/rfc9364
Copyright Notice
Copyright (c) 2023 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 ( ) in effect on the date of publication of this
document. Please review these documents carefully, as they describe your rights and restrictions
https://trustee.ietf.org/license-info
Hoffman Best Current Practice Page 1

with respect to this document. Code Components extracted from this document must include
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1.  Introduction
1.1.  DNSSEC as a Best Current Practice
1.2.  Implementing DNSSEC
2.  DNSSEC Core Documents
2.1.  Addition to the DNSSEC Core
3.  Additional Cryptographic Algorithms and DNSSEC
4.  Extensions to DNSSEC
5.  Additional Documents of Interest
6.  IANA Considerations
7.  Security Considerations
8.  References
8.1.  Normative References
8.2.  Informative References
Acknowledgements
Author's Address
1. Introduction
The core specification for what we know as DNSSEC (the combination of , ,
and ) describes a set of protocols that provide origin authentication of DNS data.
 updates and extends those core RFCs but does not fundamentally change the way that
DNSSEC works.
This document lists RFCs that should be considered by someone creating an implementation of,
or someone deploying, DNSSEC as it is currently standardized. Although an effort was made to be
thorough, the reader should not assume this list is comprehensive. It uses terminology from
those documents without defining that terminology. It also points to the relevant IANA registry
groups that relate to DNSSEC. It does not, however, point to standards that rely on zones needing
to be signed by DNSSEC, such as DNS-Based Authentication of Named Entities (DANE) .
[RFC4033] [RFC4034]
[RFC4035]
[RFC6840]
[RFC6698]
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 2

1.1. DNSSEC as a Best Current Practice
Using the DNSSEC set of protocols is the best current practice for adding origin authentication of
DNS data. To date, no Standards Track RFCs offer any other method for such origin
authentication of data in the DNS.
More than 15 years after the DNSSEC specification was published, it is still not widely deployed.
Recent estimates are that fewer than 10% of the domain names used for websites are signed, and
only around a third of queries to recursive resolvers are validated. However, this low level of
deployment does not affect whether using DNSSEC is a best current practice; it just indicates that
the value of deploying DNSSEC is often considered lower than the cost. Nonetheless, the
significant deployment of DNSSEC beneath some top-level domains (TLDs) and the near-
universal deployment of DNSSEC for the TLDs in the DNS root zone demonstrate that DNSSEC is
applicable for implementation by both ordinary and highly sophisticated domain owners.
1.2. Implementing DNSSEC
Developers of validating resolvers and authoritative servers, as well as operators of validating
resolvers and authoritative servers, need to know the parts of the DNSSEC protocol that would
affect them. They should read the DNSSEC core documents and probably at least be familiar with
the extensions. Developers will probably need to be very familiar with the algorithm documents
as well.
As a side note, some of the DNSSEC-related RFCs have significant errata, so reading the RFCs
should also include looking for the related errata.
2. DNSSEC Core Documents
What we refer to as "DNSSEC" is the third iteration of the DNSSEC specification;  was
the first, and  was the second. Earlier iterations have not been deployed on a
significant scale. Throughout this document, "DNSSEC" means the protocol initially defined in
, , and .
The three initial core documents generally cover different topics:
 is an overview of DNSSEC, including how it might change the resolution of DNS
queries.
 specifies the DNS resource records used in DNSSEC. It obsoletes many RFCs about
earlier versions of DNSSEC.
 covers the modifications to the DNS protocol incurred by DNSSEC. These include
signing zones, serving signed zones, resolving in light of DNSSEC, and authenticating
DNSSEC-signed data.
[RFC2065]
[RFC2535]
[RFC4033] [RFC4034] [RFC4035]
• [RFC4033]
• [RFC4034]
• [RFC4035]
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 3

At the time this set of core documents was published, someone could create a DNSSEC
implementation of signing software, of a DNSSEC-aware authoritative server, and/or of a
DNSSEC-aware recursive resolver from the three core documents, plus a few older RFCs
specifying the cryptography used. Those two older documents are the following:
 defines how to use the DSA signature algorithm (although it refers to other
documents for the details). DSA was thinly implemented and can safely be ignored by
DNSSEC implementations.
 defines how to use the RSA signature algorithm (although refers to other
documents for the details). RSA is still among the most popular signing algorithms for
DNSSEC.
It is important to note that later RFCs update the core documents. As just one example,
changes how TTL values are calculated in DNSSEC processing.
• [RFC2536]
• [RFC3110]
[RFC9077]
2.1. Addition to the DNSSEC Core
As with any major protocol, developers and operators discovered issues with the original core
documents over the years.  is an omnibus update to the original core documents and
thus itself has become a core document. In addition to covering new requirements from new
DNSSEC RFCs, it describes many important security and interoperability issues that arose during
the deployment of the initial specifications, particularly after the DNS root was signed in 2010. It
also lists some errors in the examples of the core specifications.
 brings a few additions into the core of DNSSEC. It makes NSEC3  as much a
part of DNSSEC as NSEC is. It also makes the SHA-256 and SHA-512 hash functions defined in
 and  part of the core.
[RFC6840]
[RFC6840] [RFC5155]
[RFC4509] [RFC5702]
3. Additional Cryptographic Algorithms and DNSSEC
Current cryptographic algorithms typically weaken over time as computing power improves and
new cryptoanalysis emerges. Two new signing algorithms have been adopted by the DNSSEC
community: Elliptic Curve Digital Signature Algorithm (ECDSA)  and Edwards-curve
Digital Signature Algorithm (EdDSA) . ECDSA and EdDSA have become very popular
signing algorithms in recent years. The GOST signing algorithm  was also adopted
but has seen very limited use, likely because it is a national algorithm specific to a very small
number of countries.
Implementation developers who want to know which algorithms to implement in DNSSEC
software should refer to . Note that this specification is only about what algorithms
should and should not be included in implementations, i.e., it is not advice about which
algorithms zone operators should or should not use for signing, nor which algorithms recursive
resolver operators should or should not use for validation.
[RFC6605]
[RFC8080]
[GOST-SIGN]
[RFC8624]
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 4

4. Extensions to DNSSEC
The DNSSEC community has extended the DNSSEC core and the cryptographic algorithms, both
in terms of describing good operational practices and in new protocols. Some of the RFCs that
describe these extensions include the following:
 describes a method to help resolvers update their DNSSEC trust anchors in an
automated fashion. This method was used in 2018 to update the DNS root trust anchor.
 is a compendium of operational practices that may not be obvious from reading
just the core specifications.
 describes using the CDS and CDNSKEY resource records to help automate the
maintenance of DS records in the parents of signed zones.
 extends  by showing how to do initial setup of trusted relationships
between signed parent and child zones.
 describes how a validating resolver can emit fewer queries in signed zones that
use NSEC and NSEC3 for negative caching.
 updates  with respect to the TTL fields in signed records.
• [RFC5011]
• [RFC6781]
• [RFC7344]
• [RFC8078] [RFC7344]
• [RFC8198]
• [RFC9077] [RFC8198]
5. Additional Documents of Interest
The documents listed above constitute the core of DNSSEC, the additional cryptographic
algorithms, and the major extensions to DNSSEC. This section lists some additional documents
that someone interested in implementing or operating DNSSEC might find of value:
 "describes how to construct DNSSEC NSEC resource records that cover a smaller
range of names than called for by . By generating and signing these records on
demand, authoritative name servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a signed zone".
 "specifies a way for validating end-system resolvers to signal to a server which
digital signature and hash algorithms they support".
 "provides additional background commentary and some context for the NSEC and
NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses".
This background is particularly important for understanding NSEC and NSEC3 usage.
 "describes the issues surrounding the timing of events in the rolling of a key in a
DNSSEC-secured zone".
 "defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC
validation failures by disabling DNSSEC validation at specified domains".
 "describes the format and publication mechanisms IANA has used to distribute
the DNSSEC trust anchors".
 "describes problems that a Validating DNS resolver, stub-resolver, or application
might run into within a non-compliant infrastructure".
• [RFC4470]
[RFC4034]
• [RFC6975]
• [RFC7129]
• [RFC7583]
• [RFC7646]
• [RFC7958]
• [RFC8027]
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 5

[RFC3110]
[RFC4033]
8. References
8.1. Normative References
,
, , , May 2001,
.
, , , , and ,
, , , March 2005,
.
 "specifies two different ways for validating resolvers to signal to a server which
keys are referenced in their chain of trust".
 contains lists of terminology used when talking about DNS; Sections 10 and 11
cover DNSSEC.
 "specifies a mechanism that will allow an end user and third parties to determine
the trusted key state for the root key of the resolvers that handle that user's DNS queries".
 "presents deployment models that accommodate this scenario [when each DNS
provider independently signs zone data with their own keys] and describes these key-
management requirements".
 "provides guidance on setting NSEC3 parameters based on recent operational
deployment experience".
There will certainly be other RFCs related to DNSSEC that are published after this one.
• [RFC8145]
• [RFC8499]
• [RFC8509]
• [RFC8901]
• [RFC9276]
6. IANA Considerations
IANA already has three registry groups that relate to DNSSEC:
DNSSEC algorithm numbers
DNSSEC NSEC3 parameters
DNSSEC DS RRtype digest algorithms
The rules for the DNSSEC algorithm registry were set in the core RFCs and updated by ,
, and .
This document does not update or create any registry groups or registries.
•
•
•
[RFC6014]
[RFC6725] [RFC9157]
7. Security Considerations
All of the security considerations from all of the RFCs referenced in this document apply here.
Eastlake 3rd, D."RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS)"RFC 3110DOI 10.17487/RFC3110 <https://www.rfc-editor.org/
info/rfc3110>
Arends, R.Austein, R.Larson, M.Massey, D. S. Rose"DNS Security
Introduction and Requirements"RFC 4033DOI 10.17487/RFC4033
<https://www.rfc-editor.org/info/rfc4033>
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 6

[RFC4034]
[RFC4035]
[RFC4509]
[RFC5155]
[RFC5702]
[RFC6840]
[GOST-SIGN]
[RFC2065]
[RFC2535]
[RFC2536]
[RFC4470]
[RFC5011]
, , , , and ,
, , , March 2005,
.
, , , , and ,
, ,
, March 2005, .
,
, , , May 2006,
.
, , , and ,
, , , March
2008, .
,
, , , October 2009,
.
 and ,
, , , February 2013,
.
8.2. Informative References
, , and ,
,
, , 30 November
2022, .
 and , ,
, , January 1997,
.
, , ,
, March 1999, .
, ,
, , March 1999,
.
 and ,
, , , April 2006,
.
, ,
, , , September 2007,
.
Arends, R.Austein, R.Larson, M.Massey, D. S. Rose"Resource Records for
the DNS Security Extensions"RFC 4034DOI 10.17487/RFC4034
<https://www.rfc-editor.org/info/rfc4034>
Arends, R.Austein, R.Larson, M.Massey, D. S. Rose"Protocol
Modifications for the DNS Security Extensions"RFC 4035DOI 10.17487/
RFC4035 <https://www.rfc-editor.org/info/rfc4035>
Hardaker, W."Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource
Records (RRs)"RFC 4509DOI 10.17487/RFC4509 <https://www.rfc-
editor.org/info/rfc4509>
Laurie, B.Sisson, G.Arends, R. D. Blacka"DNS Security (DNSSEC) Hashed
Authenticated Denial of Existence"RFC 5155DOI 10.17487/RFC5155
<https://www.rfc-editor.org/info/rfc5155>
Jansen, J."Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource
Records for DNSSEC"RFC 5702DOI 10.17487/RFC5702 <https://
www.rfc-editor.org/info/rfc5702>
Weiler, S., Ed.D. Blacka, Ed."Clarifications and Implementation Notes for
DNS Security (DNSSEC)"RFC 6840DOI 10.17487/RFC6840
<https://www.rfc-editor.org/info/rfc6840>
Belyavsky, D.Dolmatov, V., Ed.B. Makarenko, Ed."Use of GOST 2012
Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC"
Work in ProgressInternet-Draft, draft-ietf-dnsop-rfc5933-bis-13
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-13>
Eastlake 3rd, D.C. Kaufman"Domain Name System Security Extensions"
RFC 2065DOI 10.17487/RFC2065 <https://www.rfc-editor.org/info/
rfc2065>
Eastlake 3rd, D."Domain Name System Security Extensions"RFC 2535DOI
10.17487/RFC2535 <https://www.rfc-editor.org/info/rfc2535>
Eastlake 3rd, D."DSA KEYs and SIGs in the Domain Name System (DNS)"RFC
2536DOI 10.17487/RFC2536 <https://www.rfc-editor.org/info/
rfc2536>
Weiler, S. J. Ihren"Minimally Covering NSEC Records and DNSSEC On-line
Signing"RFC 4470DOI 10.17487/RFC4470 <https://www.rfc-
editor.org/info/rfc4470>
StJohns, M."Automated Updates of DNS Security (DNSSEC) Trust Anchors"STD
74RFC 5011DOI 10.17487/RFC5011 <https://www.rfc-
editor.org/info/rfc5011>
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 7

[RFC6014]
[RFC6605]
[RFC6698]
[RFC6725]
[RFC6781]
[RFC6975]
[RFC7129]
[RFC7344]
[RFC7583]
[RFC7646]
[RFC7958]
[RFC8027]
, ,
, , November 2010,
.
 and ,
, , , April 2012,
.
 and ,
, ,
, August 2012, .
, ,
, , August 2012,
.
, , and ,
, , , December 2012,
.
 and ,
, , , July 2013,
.
 and , ,
, , February 2014,
.
, , and ,
, , , September 2014,
.
, , , and ,
, , , October 2015,
.
, , , , and ,
, , ,
September 2015, .
, , , and ,
, , , August 2016,
.
, , and ,
, , , , November 2016,
.
Hoffman, P."Cryptographic Algorithm Identifier Allocation for DNSSEC"RFC
6014DOI 10.17487/RFC6014 <https://www.rfc-editor.org/info/
rfc6014>
Hoffman, P. W.C.A. Wijngaards"Elliptic Curve Digital Signature Algorithm
(DSA) for DNSSEC"RFC 6605DOI 10.17487/RFC6605 <https://
www.rfc-editor.org/info/rfc6605>
Hoffman, P. J. Schlyter"The DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS) Protocol: TLSA"RFC 6698DOI 10.17487/
RFC6698 <https://www.rfc-editor.org/info/rfc6698>
Rose, S."DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates"
RFC 6725DOI 10.17487/RFC6725 <https://www.rfc-editor.org/info/
rfc6725>
Kolkman, O.Mekking, W. R. Gieben"DNSSEC Operational Practices,
Version 2"RFC 6781DOI 10.17487/RFC6781 <https://www.rfc-
editor.org/info/rfc6781>
Crocker, S. S. Rose"Signaling Cryptographic Algorithm Understanding in
DNS Security Extensions (DNSSEC)"RFC 6975DOI 10.17487/RFC6975
<https://www.rfc-editor.org/info/rfc6975>
Gieben, R. W. Mekking"Authenticated Denial of Existence in the DNS"RFC
7129DOI 10.17487/RFC7129 <https://www.rfc-editor.org/info/
rfc7129>
Kumari, W.Gudmundsson, O.G. Barwood"Automating DNSSEC Delegation
Trust Maintenance"RFC 7344DOI 10.17487/RFC7344 <https://
www.rfc-editor.org/info/rfc7344>
Morris, S.Ihren, J.Dickinson, J. W. Mekking"DNSSEC Key Rollover Timing
Considerations"RFC 7583DOI 10.17487/RFC7583 <https://
www.rfc-editor.org/info/rfc7583>
Ebersman, P.Kumari, W.Griffiths, C.Livingood, J. R. Weber"Definition
and Use of DNSSEC Negative Trust Anchors"RFC 7646DOI 10.17487/RFC7646
<https://www.rfc-editor.org/info/rfc7646>
Abley, J.Schlyter, J.Bailey, G. P. Hoffman"DNSSEC Trust Anchor
Publication for the Root Zone"RFC 7958DOI 10.17487/RFC7958
<https://www.rfc-editor.org/info/rfc7958>
Hardaker, W.Gudmundsson, O.S. Krishnaswamy"DNSSEC Roadblock
Avoidance"BCP 207RFC 8027DOI 10.17487/RFC8027 <https://
www.rfc-editor.org/info/rfc8027>
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 8

[RFC8078]
[RFC8080]
[RFC8145]
[RFC8198]
[RFC8499]
[RFC8509]
[RFC8624]
[RFC8901]
[RFC9077]
[RFC9157]
[RFC9276]
 and ,
, , , March 2017,
.
 and ,
, , , February 2017,
.
, , and ,
, , , April
2017, .
, , and ,
, , , July 2017,
.
, , and , , ,
, , January 2019,
.
, , and ,
, , , December 2018,
.
 and ,
, , , June 2019,
.
, , , , and ,
, , , September 2020,
.
, , ,
, July 2021, .
, , ,
, December 2021, .
 and , ,
, , , August 2022,
.
Gudmundsson, O.P. Wouters"Managing DS Records from the Parent via
CDS/CDNSKEY"RFC 8078DOI 10.17487/RFC8078 <https://www.rfc-
editor.org/info/rfc8078>
Sury, O. R. Edmonds"Edwards-Curve Digital Security Algorithm (EdDSA) for
DNSSEC"RFC 8080DOI 10.17487/RFC8080 <https://www.rfc-
editor.org/info/rfc8080>
Wessels, D.Kumari, W. P. Hoffman"Signaling Trust Anchor Knowledge in
DNS Security Extensions (DNSSEC)"RFC 8145DOI 10.17487/RFC8145
<https://www.rfc-editor.org/info/rfc8145>
Fujiwara, K.Kato, A. W. Kumari"Aggressive Use of DNSSEC-Validated
Cache"RFC 8198DOI 10.17487/RFC8198 <https://www.rfc-editor.org/
info/rfc8198>
Hoffman, P.Sullivan, A. K. Fujiwara"DNS Terminology"BCP 219RFC
8499DOI 10.17487/RFC8499 <https://www.rfc-editor.org/info/
rfc8499>
Huston, G.Damas, J. W. Kumari"A Root Key Trust Anchor Sentinel for
DNSSEC"RFC 8509DOI 10.17487/RFC8509 <https://www.rfc-
editor.org/info/rfc8509>
Wouters, P. O. Sury"Algorithm Implementation Requirements and Usage
Guidance for DNSSEC"RFC 8624DOI 10.17487/RFC8624 <https://
www.rfc-editor.org/info/rfc8624>
Huque, S.Aras, P.Dickinson, J.Vcelak, J. D. Blacka"Multi-Signer DNSSEC
Models"RFC 8901DOI 10.17487/RFC8901 <https://www.rfc-
editor.org/info/rfc8901>
van Dijk, P."NSEC and NSEC3: TTLs and Aggressive Use"RFC 9077DOI
10.17487/RFC9077 <https://www.rfc-editor.org/info/rfc9077>
Hoffman, P."Revised IANA Considerations for DNSSEC"RFC 9157DOI 10.17487/
RFC9157 <https://www.rfc-editor.org/info/rfc9157>
Hardaker, W.V. Dukhovni"Guidance for NSEC3 Parameter Settings"BCP
236RFC 9276DOI 10.17487/RFC9276 <https://www.rfc-editor.org/
info/rfc9276>
Acknowledgements
The DNS world owes a depth of gratitude to the authors and other contributors to the core
DNSSEC documents and to the notable DNSSEC extensions.
In addition, the following people made significant contributions to early draft versions of this
document:  and .Ben SchwartzDuane Wessels
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 9

Author's Address
Paul Hoffman
ICANN
 paul.hoffman@icann.org Email:
RFC 9364 DNSSEC February 2023
Hoffman Best Current Practice Page 10


ICANN Announcements

ICANN Announcements
العربية
中文
English
Français
Pусский
Español
Logo
en
Search
Search
Search
Filtered Search
Log In
Sign Up
Are you sure you want to sign out from
https://www.icann.org
?
Yes
Cancel
If you want to sign out from both
https://www.icann.org
and ICANN Account,
click here
.
ICANN
Get Started
News and Media
Policy
Public Comment
Resources
Community
Quicklinks
Get Started
News and Media
Policy
Public Comment
Resources
Community
Quicklinks
ICANN Announcements
Read ICANN Announcements to stay informed of the latest policymaking activities, regional events, and more.
Subscribe
ICANN.org Home
Announcements
Blogs
Engagement Calendar
Follow Us on Social
Media Resources
ICANN Announcements
Advanced Search
Select filters and click Apply to narrow your search results or click More Search Options to search for keywords within Announcements.
Start Date
End Date
Region(s)
Africa
Asia/Australia/Pacific
Europe
Latin America/Caribbean
North America
Apply
Clear
More Search Options
1-20 of 4303 results
ICANN Adjusts Evaluation Fee Payment Timeline for 2026 Round Applicants
7 August 2026
ICANN Request for Proposal: Event Sponsorship Management
7 August 2026
ICANN Provides Update on Community’s Continuous Improvement Program Progress
6 August 2026
ICANN Request for Proposal: Governance, Risk, and Compliance Solution
5 August 2026
ICANN Publishes String Similarity Evaluation Data and Guidelines
30 July 2026
Last Call: Nominations for Dr. Tarek Kamel Award for Capacity Building
28 July 2026
ICANN Releases Updated Root KSK Rollover Guide for the Community
27 July 2026
ICANN87 Community Childcare Grants Program: Apply Now
27 July 2026
ICANN88 Fellowship Application Round Now Open
21 July 2026
Reminder: ICANN 2026 Round New gTLD Application Window Closes 12 August
13 July 2026
ICANN 2026 Round Registry Service Provider Evaluation Program Closes 12 August
8 July 2026
ICANN Announces NextGen@ICANN87 Participants
8 July 2026
Registration for ICANN87 in Bali, Indonesia, Is Now Open
6 July 2026
IANA Satisfaction Survey Shows Strong Support and Continued Trust
2 July 2026
Join the ICANN Webinars: Review of Reviews Draft Report
1 July 2026
ICANN Seeks Input on IGO and INGO Curative Rights Implementation
30 June 2026
ICANN Opens Nomination Period for Dr. Tarek Kamel Award for Capacity Building
30 June 2026
ICANN Review of Reviews CCG Seeks Feedback on Draft Report
26 June 2026
ICANN Publishes Updated Evaluation Guide for Community Priority Evaluation
24 June 2026
ICANN Announces Recipients of the ICANN87 Fellowship
18 June 2026
Previous
1
2
3
4
5
...
216
Next
Previous
1
2
3
...
216
Next
Connect with us
X
Instagram
Facebook
Youtube
LinkedIn
Flickr
Soundcloud
Explore Our Social Media Hub and Follow Us on ICANN's Official Accounts
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability and Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Requests for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers
Privacy Policy
Terms of Service
Cookies Policy
Privacy Policy
Terms of Service
Cookies Policy

7 August 2026

Month Year date pattern in document text


[2301.01234] AmbieGen: A Search-based Framework for Autonomous Systems Testing
Skip to main content
arXiv is now an independent nonprofit!
Learn more
×
Search
Submit
Donate
Log in
Search arXiv
Press Enter to search ·
Advanced search
Computer Science > Robotics
arXiv:2301.01234
(cs)
[Submitted on 1 Jan 2023]
Title:
AmbieGen: A Search-based Framework for Autonomous Systems Testing
Authors:
Dmytro Humeniuk
,
Foutse Khomh
,
Giuliano Antoniol
View a PDF of the paper titled AmbieGen: A Search-based Framework for Autonomous Systems Testing, by Dmytro Humeniuk and 1 other authors
View PDF
Abstract:
Thorough testing of safety-critical autonomous systems, such as self-driving cars, autonomous robots, and drones, is essential for detecting potential failures before deployment. One crucial testing stage is model-in-the-loop testing, where the system model is evaluated by executing various scenarios in a simulator. However, the search space of possible parameters defining these test scenarios is vast, and simulating all combinations is computationally infeasible. To address this challenge, we introduce AmbieGen, a search-based test case generation framework for autonomous systems. AmbieGen uses evolutionary search to identify the most critical scenarios for a given system, and has a modular architecture that allows for the addition of new systems under test, algorithms, and search operators. Currently, AmbieGen supports test case generation for autonomous robots and autonomous car lane keeping assist systems. In this paper, we provide a high-level overview of the framework's architecture and demonstrate its practical use cases.
Comments:
17 pages, 10 figures
Subjects:
Robotics (cs.RO)
; Neural and Evolutionary Computing (cs.NE)
Cite as:
arXiv:2301.01234
[cs.RO]
(or
arXiv:2301.01234v1
[cs.RO]
for this version)
https://doi.org/10.48550/arXiv.2301.01234
Focus to learn more
arXiv-issued DOI via DataCite
Submission history
From: Dmytro Humeniuk [
view email
]
[v1]
Sun, 1 Jan 2023 23:42:32 UTC (1,117 KB)
Full-text links:
Access Paper:
View a PDF of the paper titled AmbieGen: A Search-based Framework for Autonomous Systems Testing, by Dmytro Humeniuk and 1 other authors
View PDF
TeX Source
view license
Current browse context:
cs.RO
< prev
|
next >
new
|
recent
|
2023-01
Change to browse by:
cs
cs.NE
References & Citations
NASA ADS
Google Scholar
Semantic Scholar
export BibTeX citation
Loading...
BibTeX formatted citation
×
loading...
Data provided by:
Bookmark
Bibliographic Tools
Bibliographic and Citation Tools
Bibliographic Explorer Toggle
Bibliographic Explorer
(
What is the Explorer?
)
Connected Papers Toggle
Connected Papers
(
What is Connected Papers?
)
Litmaps Toggle
Litmaps
(
What is Litmaps?
)
scite.ai Toggle
scite Smart Citations
(
What are Smart Citations?
)
Code, Data, Media
Code, Data and Media Associated with this Article
alphaXiv Toggle
alphaXiv
(
What is alphaXiv?
)
Links to Code Toggle
CatalyzeX Code Finder for Papers
(
What is CatalyzeX?
)
DagsHub Toggle
DagsHub
(
What is DagsHub?
)
GotitPub Toggle
Gotit.pub
(
What is GotitPub?
)
Huggingface Toggle
Hugging Face
(
What is Huggingface?
)
ScienceCast Toggle
ScienceCast
(
What is ScienceCast?
)
Demos
Demos
Replicate Toggle
Replicate
(
What is Replicate?
)
Spaces Toggle
Hugging Face Spaces
(
What is Spaces?
)
Spaces Toggle
TXYZ.AI
(
What is TXYZ.AI?
)
Related Papers
Recommenders and Search Tools
Link to Influence Flower
Influence Flower
(
What are Influence Flowers?
)
Core recommender toggle
CORE Recommender
(
What is CORE?
)
Author
Venue
Institution
Topic
About arXivLabs
arXivLabs: experimental projects with community collaborators
arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.
Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.
Have an idea for a project that will add value for arXiv's community?
Learn more about arXivLabs
.
Which authors of this paper are endorsers?
|
Disable MathJax
(
What is MathJax?
)
We gratefully acknowledge support from
our
major funders
,
member institutions
,
,
and all contributors.
About
·
Help
·
Contact
·
Subscribe
·
Copyright
·
Privacy
·
Accessibility
·
Operational Status
(opens in new tab)
Major funding support from


IGF 2026 First Open Consultations and MAG Meeting | Internet Governance Forum (IGF)
Skip to main content
Welcome to the United Nations
|
Department of Economic and Social Affairs
English
English
Menu
Quick links
I am new to the IGF
Subscribe to our mailing list
Register for an IGF activity
Donate to the IGF
Find/Become a Resource Person
Search
Feed me
Log in
Header Menu
About
About
About IGF
FAQs – About IGF & IGF 2025
Get Started
Team
IGF Donors
Work With Us
IGF Mailing Lists
Contact Us
IGF Leadership Panel
Multi-stakeholder Advisory Group
Multi-stakeholder Advisory Group
MAG Terms of Reference
MAG Chair Terms of Reference
MAG Chair's Blog
MAG Members
MAG Members
Previous MAG Members
MAG Working Groups
MAG Meeting Records
MAG Activities
MAG Member Dashboard
IGF 2026 MAG Renewal
UN Global Advocate
IGF Expert Group Meeting (2026)
IGF Expert Group Meeting 2026
EGM Report
The IGF and UN Processes
Code of Conduct
Newsletter
Press
Support the IGF
Donate
IGF Trust Fund
Donors' Contributions to Main Trust Fund
Global South Contributions
Host the IGF
Share Your Experience - "Voices of the IGF"
IGF 2026
IGF 2026 Entry Page
IGF 2026 Call for Session Proposals
IGF 2026 Call for Village Booths
IGF 2026 Call for Remote Hubs
IGF 2026 First Open Consultations & MAG Meeting
IGF 2026 Timeline
IGF 2026 Intersessional Work Proposals
IGF 2026 Proposed Thematic Inputs
IGF 2025 Stocktaking & 2026 Improvements
IGF 2026 Call for MAG Nominations
IGF 2026 Call for NRI Grants
IGF 2026 Judiciary Engagement
IGF 2026 Parliamentary Track
IGF 2026 Youth Track
IGF 2026 Business Engagement
Intersessional Work
Thematic Intersessional Work
Dynamic Coalitions
Dynamic Coalitions
DC Coordination Activities
Terms of Reference
Best Practice Forums
Policy Networks
Policy Network on Artificial Intelligence
Policy Network on Cybersecurity
Policy Network on Open Digital Infrastructure
Policy Network on Digital Inclusion
Previous Work
Capacity Development
Intersessional News
National and Regional IGFs
Overview
NRIs FAQs
NRIs Toolkit: How to Start Your IGF Initiative?
Youth Initiatives
Regional IGF Initiatives
National IGF Initiatives
All National Initiatives
Africa
Asia Pacific
Eastern Europe
GRULAC
WEOG
NRI Dashboard
NRIs Library
NRIs Collaborative Work
IGF 2026 NRIs Preparatory Process
Brochures about NRIs
IGF NRIs Call for Grants
NRIs Meetings - overview
Publications and Reports
IGF Brochures and Select Publications
Publications and Reports
IGF Annual Meeting Proceedings
IGF Intersessional Work
CSTD Reports
UN GA Resolutions on ICT for SD
Calendar
Breadcrumb
Home
IGF 2026 First Open Consultations and MAG Meeting
Documents & Records
Agenda
Registration, Venue & Travel Information
*List continuously updated
Meeting Videos
Day 1 Morning
|
Day 1 Afternoon
|
Day 2 Morning
|
Day 2 Afternoon
|
Day 3
Welcome Message - Junhua Li, UN Under-Secretary-General for Economic and Social Affairs
Meeting Documents
Update on Youth Track
Update on NRIs
IGF Programme Architecture
IGF 2025 Call for Session Proposals
IGF Workshop Evaluation Process 2026
Host Country Presentation on Overarching Themes
IGF Themes & Subthemes 2006-2025
IGF 2026 Draft MAG Timeline
IGF 2025 Call for Village Booths
IGF 2025 Call for Remote Hubs
IGF 2025 Taking Stock Inputs
IGF 2026 Call for Thematic Inputs: Results
Outcomes of Virtual MAG Meetings I–III
IGF Expert Group Meeting (EGM) on Implementing the IGF Permanent Mandate - Summary Report (April 2026)
Written Inputs from Organizations
RIPE NCC
UN Economic Commission on Africa (UN ECA)
Internet Society (ISOC)
OECD:
Recommendation on Quantum Technologies
|
AI Policy Toolkit
|
2026 Going Digital Integrated Policy Framework
|
2026 Going Digital Measurement Roadmap
|
Growing Up in the Social Media Age
YouthDIG
Internet Society Colombia
First
IGF
2026 Open Consultations and Multistakeholder Advisory Group (
MAG
) Meeting
DRAFT AGENDA
24-26 June 2026 | UN Office at Nairobi (UNON) & Online
LIVESTREAM LINK:
https://youtube.com/@igf/live
Targeted Outputs of Day 1
Gather community input on the overall direction of
IGF
2026 and programme priorities.
Discuss strategic priorities for
IGF
2026, including in the context of
WSIS
+20, implementation of the Global Digital Compact, Global Dialogue on AI Governance and other major governance processes.
Identify considerations to inform subsequent
MAG
discussions on programme development.
Input Documents (*continuously updated)
Host Country Presentation on Overarching Themes
IGF 2026 Draft MAG Timeline
IGF 2025 Taking Stock Inputs
IGF Themes & Subthemes 2006-2025
IGF 2026 Call for Thematic Inputs: Results
Outcomes of Virtual MAG Meetings I–III
IGF Expert Group Meeting (EGM) on Implementing the IGF Permanent Mandate - Summary Report (April 2026)
Day 1 – 24 June 2026 (Open Consultations)
Mt. Kilimanjaro Room, UNON – 09:30-12:30 |
Conference Room 10, UNON – 14:00-17:00
Time (EAT)
Agenda Item
09:30 – 10:15
Opening statements and adoption of the agenda
Welcome by
MAG
Chair and adoption of the agenda
Welcome by Host Country Co-Chair and Alternates
Welcome by UN DESA
Host Country update on preparations, followed by Q&A
10:15 – 10:30
IGF
2025 stocktaking and considerations for
IGF
2026
IGF
Secretariat summary of stocktaking inputs and key lessons for 2026
10:30 – 10:45
Short break
10:45 – 12:30
Inputs on
IGF
2026 programme, including in the context of
WSIS
+20, the Global Digital Compact (GDC), Global Dialogue on AI Governance and other major digital governance processes
Interventions from
IGF
partner organizations and relevant UN entities on opportunities for alignment between the
IGF
2026 programme and their respective workstreams, priorities and implementation activities
Open discussion on how the
IGF
2026 programme can reflect the role of the
IGF
ecosystem in implementation and follow-up of above processes
12:30 – 14:00
Lunch
14:00 – 15:30
IGF
2026 overarching theme
Host Country overarching theme suggestions and priorities
Open discussion on
IGF
2026 overarching theme
15:30 – 15:45
Short break
15:45 – 16:50
Strategic priorities for
IGF
2026
Open discussion on programme priorities, emerging issues and strategic objectives for
IGF
2026
Discussion of relevant recommendations emerging from the April 2026 Expert Group Meeting (EGM), including strengthening coherence across the
IGF
ecosystem, enhancing linkages between annual, intersessional and
NRI
activities, capacity development, and strengthening the
IGF
's contribution to implementation of
WSIS
+20, GDC, Global Dialogue on AI Governance, and other digital governance processes
16:50 – 17:00
Objectives for the next two days, summing up and closing
Targeted Outputs of Day 2
Confirm outcomes of
MAG
virtual meetings, including
MAG
-approved intersessional policy activities and working groups.
Agree on programme architecture for
IGF
2026.
Consider relevant EGM recommendations concerning programme design, ecosystem coherence, capacity development and stakeholder engagement.
Discuss possible approaches to a Government Dialogue component at
IGF
2026, taking into account recommendations from the April 2026 EGM.
Review public calls and evaluation processes.
Input Documents (*continuously updated)
Update on Youth Track
Update on NRIs
IGF 2025 Call for Session Proposals

IGF 2025 Call for Village Booths

IGF 2025 Call for Remote Hubs
IGF Programme Architecture
IGF Themes & Subthemes 2006-2025
IGF 2026 Call for Thematic Inputs: Results
Outcomes of Virtual MAG Meetings I–III
IGF Expert Group Meeting (EGM) on Implementing the IGF Permanent Mandate – Summary Report (April 2026)
Day 2 – 25 June 2026 (
MAG
Meeting)
Conference Room 10, UNON
Time (EAT)
Agenda Item
09:30 – 09:45
Opening of the
MAG
meeting and recap from the Open Consultations
09:45 – 10:00
Confirmation of outcomes of virtual
MAG
meetings
MAG
-approved intersessional policy activities
MAG
Working Groups
10:00 – 10:30
MAG
-approved intersessional policy activities and
MAG
Working Groups
Discussion of work plans and coordination mechanisms
10:30 – 10:45
Short Break
10:45 – 11:45
Leveraged collaboration with and between
IGF
Dynamic Coalitions (DCs), National and Regional
IGF
Initiatives (
NRIs
) and capacity development initiatives
Updates from Dynamic Coalitions
Updates from
NRIs
Updates from Youth Track
11:45 – 12:30
Overall programme structure and flow
Programme architecture and thematic organization
Session types, with view to streamlining/simplification
12:30 – 14:00
Lunch
14:00 – 15:00
Overall programme structure and flow (cont’d.)
Integration of intersessional work,
NRIs
, youth, parliamentary track, judiciary and business engagement activities
Consideration of EGM recommendations on strengthening coherence across the
IGF
ecosystem, including stronger integration of intersessional work,
NRIs
and capacity development activities into the annual meeting programme – taking into account updates from DCs and
NRIs
15:00 – 15:30
Government Dialogue at
IGF
2026
Discussion of EGM recommendations on enhanced government engagement through adaptation of existing programme formats
Possible objectives, format and relationship to existing high-level and ministerial activities
15:30 – 15:45
Short break
15:45 – 16:50
Review of
IGF
public calls and preparation for
IGF
2026 calls
Call for Session Proposals
Call for Village Booth Proposals
Call for Remote Hub Proposals
16:50 – 17:00
Recap of consensus, next steps and closing
Targeted Outputs of Day 3
Endorse the Call for Sessions package.
Agree on session evaluation procedures.
Discuss strategic priorities for
IGF
2026 cycle.
Prepare for the September 2026 Open Consultations and
MAG
Meeting.
Input Documents (*continuously updated)
IGF 2025 Call for Session Proposals
IGF Workshop Evaluation Process 2026
IGF 2026 Draft Timeline
IGF Expert Group Meeting (EGM) on Implementing the IGF Permanent Mandate – Summary Report (April 2026)
Day 3 – 26 June 2026 (
MAG
Meeting)
Conference Room 10, UNON
Time (EAT)
Agenda Item
09:30 – 09:40
Review of the agenda and meeting goals
09:40 – 10:30
Call for Session Proposals and evaluation procedures
Review and endorsement of evaluation criteria and processes
10:30 – 10:45
Short break
10:45 – 12:30
Strategic priorities for
IGF
2026 cycle
Discussion of priorities for the remainder of the
MAG
cycle
Review of relevant EGM recommendations related to impact, including policy impacts through ‘Policy Labs’, and the development of more actionable and policy-relevant
IGF
outcomes
12:30 – 14:00
Lunch
14:00 – 15:00
Preparing for the next phase of programme development
Timeline and milestones leading to the September Open Consultations and
MAG
Meeting
15:00 – 15:15
Review of decisions and action items
15:15 – 15:30
Next steps and meeting closure
Closing remarks from the Host Country Chairs and
MAG
Chair
Participants wishing to attend the
IGF
2026 First Open Consultations and
MAG
Meeting
, taking place
24-26 June 2026
at the
United Nations Office at Nairobi (UNON), Kenya
&
Online
, are kindly requested to register in advance through the official registration platform (INDICO).
Both onsite and fully online participants must use this platform.
For those participating onsite, once the registration request has been approved, you can
collect your badge
to access UNON at the
Pass & ID Unit (next to the Visitors Pavilion)
at the
main entrance
, located directly across from the U.S. Embassy on United Nations Avenue. Collection hours on the meeting days are
8.00 - 16.00 EAT
. Please bring your valid official Passport / ID document issued by a UN member state.
The
Zoom link
will be shared with all registered participants. The meeting can also be
livestreamed
via this link:
https://youtube.com/@igf/live
Registration for Onsite & Online Participants
https://indico.un.org/event/1024132/
Venue & Hours
The meeting takes place at
UNON
from
Wednesday 24 June to Friday 26 June
according to the following standard
hours on each day
: Morning session, 9.30 - 12.30 EAT | Lunch break, 12.30 - 14.00 EAT | Afternoon session, 14.00 - 17.00 EAT (*Friday afternoon session may adjourn earlier)
The
rooms
for the meeting will be as follows: Wednesday 24 June morning - Mt. Kilimanjaro Room | Wednesday 24 June afternoon through Friday 26 June - Conference Room 10
For a
map of the venue
, please see
here
.
For
transport options to UNON
and
dining & coffee facilities
onsite, kindly see
here
.
Accommodation
Participants are responsible for arranging their own accommodation. A list of hotels and guesthouses recommended by UNON and the United Nations Department of Safety and Security (UNDSS) is available here:
https://dcs.unon.org/en/hotels-guesthouses
Travel and Entry Requirements
Participants are encouraged to review travel and entry requirements for Kenya well in advance of their departure.
Most travellers are required to obtain a Kenya Electronic Travel Authorisation (eTA) before travelling. The eTA is a digital travel authorisation issued by the Government of Kenya that determines a traveller’s eligibility to travel to Kenya and is generally required prior to boarding a flight. Participants are strongly encouraged to apply for their eTA as early as possible to avoid delays.
*Kenya Electronic Travel Authorisation (eTA)*
https://etakenya.go.ke/
Additional information on eligibility requirements and the application process is available through the official eTA portal.
General Travel Information for Kenya
Participants are also encouraged to consult the UNON General Travel Information for Kenya document, which contains practical information on entry requirements, airport arrival procedures, transportation, health considerations, currency, communications, weather conditions and other useful guidance for visitors to Nairobi:
https://dcs.unon.org/sites/default/files/2025-06/kenya_general_travel_i...
Participants are advised to make travel and accommodation arrangements as early as possible. Information contained in the above resources should be reviewed carefully prior to travel.
UNITED NATIONS
Contact information
United Nations
Secretariat of the Internet Governance Forum (IGF)
Villa Le Bocage
Palais des Nations,
CH-1211 Geneva 10
Switzerland
igf [at] un [dot] org
+41 (0) 229 173 411
Additional Information
Donate to the IGF
Participant Funding
Vacancies
Multilingualism
Accessibility Statement
Resources
Publications
Press
Glossary
CONNECT WITH US
Donate
Footer menu
Copyright
Privacy Notice
Terms of Use
Accessibility menu
Contrast settings
Font size
Letter spacing
Line height
Images
Font
Reset the settings

Year found in title: 'IGF 2026 First Open Consultations and MAG Meeting | Internet Governance Forum (IGF)'


RFC 1436: The Internet Gopher Protocol

RFC 1436: The Internet Gopher Protocol (a distributed document search and retrieval protocol) | RFC Editor
Skip to content
Info
RFC
1436
:
The Internet Gopher Protocol (a distributed document search and retrieval protocol)
F. Anklesaria
,
M. McCahill
,
P. Lindner
,
D. Johnson
,
D. Torrey
,
B. Alberti
Informational
Network Working Group                                     F. Anklesaria
Request for Comments: 1436                                  M. McCahill
                                                             P. Lindner
                                                             D. Johnson
                                                              D. Torrey
                                                             B. Alberti
                                                University of Minnesota
                                                             March 1993
The Internet Gopher Protocol
(a distributed document search and retrieval protocol)
Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   The Internet Gopher protocol is designed for distributed document
   search and retrieval.  This document describes the protocol, lists
   some of the implementations currently available, and has an overview
   of how to implement new client and server applications.  This
   document is adapted from the basic Internet Gopher protocol document
   first issued by the Microcomputer Center at the University of
   Minnesota in 1991.

Introduction

   gopher  n.  1. Any of various short tailed, burrowing mammals of the
   family Geomyidae, of North America.  2. (Amer. colloq.) Native or
   inhabitant of Minnesota: the Gopher State.  3. (Amer. colloq.) One
   who runs errands, does odd-jobs, fetches or delivers documents for
   office staff.  4. (computer tech.) software following a simple
   protocol for burrowing through a TCP/IP internet.

   The Internet Gopher protocol and software follow a client-server
   model.  This protocol assumes a reliable data stream; TCP is assumed.
   Gopher servers should listen on port 70 (port 70 is assigned to
   Internet Gopher by IANA).  Documents reside on many autonomous
   servers on the Internet.  Users run client software on their desktop
   systems, connecting to a server and sending the server a selector (a
   line of text, which may be empty) via a TCP connection at a well-
   known port.  The server responds with a block of text terminated by a
   period on a line by itself and closes the connection.  No state is
   retained by the server.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 1]
RFC 1436
Gopher                       March 1993
While documents (and services) reside on many servers, Gopher client
   software presents users with a hierarchy of items and directories
   much like a file system.  The Gopher interface is designed to
   resemble a file system since a file system is a good model for
   organizing documents and services; the user sees what amounts to one
   big networked information system containing primarily document items,
   directory items, and search items (the latter allowing searches for
   documents across subsets of the information base).

   Servers return either directory lists or documents.  Each item in a
   directory is identified by a type (the kind of object the item is),
   user-visible name (used to browse and select from listings), an
   opaque selector string (typically containing a pathname used by the
   destination host to locate the desired object), a host name (which
   host to contact to obtain this item), and an IP port number (the port
   at which the server process listens for connections). The user only
   sees the user-visible name.  The client software can locate and
   retrieve any item by the trio of selector, hostname, and port.

   To use a search item, the client submits a query to a special kind of
   Gopher server: a search server.  In this case, the client sends the
   selector string (if any) and the list of words to be matched. The
   response yields "virtual directory listings" that contain items
   matching the search criteria.

   Gopher servers and clients exist for all popular platforms.  Because
   the protocol is so sparse and simple, writing servers or clients is
   quick and straightforward.
1
.  Introduction
The Internet Gopher protocol is designed primarily to act as a
   distributed document delivery system.  While documents (and services)
   reside on many servers, Gopher client software presents users with a
   hierarchy of items and directories much like a file system.  In fact,
   the Gopher interface is designed to resemble a file system since a
   file system is a good model for locating documents and services.  Why
   model a campus-wide information system after a file system?  Several
   reasons:

      (a) A hierarchical arrangement of information is familiar to many
      users.  Hierarchical directories containing items (such as
      documents, servers, and subdirectories) are widely used in
      electronic bulletin boards and other campus-wide information
      systems. People who access a campus-wide information server will
      expect some sort of hierarchical organization to the information
      presented.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 2]
RFC 1436
Gopher                       March 1993
(b) A file-system style hierarchy can be expressed in a simple
      syntax.  The syntax used for the internet Gopher protocol is
      easily understandable, and was designed to make debugging servers
      and clients easy.  You can use Telnet to simulate an internet
      Gopher client's requests and observe the responses from a server.
      Special purpose software tools are not required.  By keeping the
      syntax of the pseudo-file system client/server protocol simple, we
      can also achieve better performance for a very common user
      activity: browsing through the directory hierarchy.

      (c) Since Gopher originated in a University setting, one of the
      goals was for departments to have the option of publishing
      information from their inexpensive desktop machines, and since
      much of the information can be presented as simple text files
      arranged in directories, a protocol modeled after a file system
      has immediate utility.  Because there can be a direct mapping from
      the file system on the user's desktop machine to the directory
      structure published via the Gopher protocol, the problem of
      writing server software for slow desktop systems is minimized.

      (d) A file system metaphor is extensible.  By giving a "type"
      attribute to items in the pseudo-file system, it is possible to
      accommodate documents other than simple text documents.  Complex
      database services can be handled as a separate type of item.  A
      file-system metaphor does not rule out search or database-style
      queries for access to documents.  A search-server type is also
      defined in this pseudo-file system.  Such servers return "virtual
      directories" or list of documents matching user specified
      criteria.
2
.  The internet Gopher Model
A detailed BNF rendering of the internet Gopher syntax is available
   in the appendix...but a close reading of the appendix may not be
   necessary to understand the internet Gopher protocol.

   In essence, the Gopher protocol consists of a client connecting to a
   server and sending the server a selector (a line of text, which may
   be empty) via a TCP connection.  The server responds with a block of
   text terminated with a period on a line by itself, and closes the
   connection.  No state is retained by the server between transactions
   with a client. The simple nature of the protocol stems from the need
   to implement servers and clients for the slow, smaller desktop
   computers (1 MB Macs and DOS machines), quickly, and efficiently.

   Below is a simple example of a client/server interaction; more
   complex interactions are dealt with later.  Assume that a "well-
   known" Gopher server (this may be duplicated, details are discussed
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 3]
RFC 1436
Gopher                       March 1993
later) listens at a well known port for the campus (much like a
   domain-name server).  The only configuration information the client
   software retains is this server's name and port number (in this
   example that machine is rawBits.micro.umn.edu and the port 70). In
   the example below the F character denotes the TAB character.

 Client:          {Opens connection to rawBits.micro.umn.edu at port 70}

 Server:          {Accepts connection but says nothing}

 Client: <CR><LF> {Sends an empty line: Meaning "list what you have"}

 Server:          {Sends a series of lines, each ending with CR LF}
 0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70
 1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70
 1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70
 1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120
 1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70
 1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70
                    {.....etc.....}
 .                  {Period on a line by itself}
                    {Server closes connection}

   The first character on each line tells whether the line describes a
   document, directory, or search service (characters '0', '1', '7';
   there are a handful more of these characters described later).  The
   succeeding characters up to the tab form a user display string to be
   shown to the user for use in selecting this document (or directory)
   for retrieval.  The first character of the line is really defining
   the type of item described on this line. In nearly every case, the
   Gopher client software will give the users some sort of idea about
   what type of item this is (by displaying an icon, a short text tag,
   or the like).

   The characters following the tab, up to the next tab form a selector
   string that the client software must send to the server to retrieve
   the document (or directory listing).  The selector string should mean
   nothing to the client software; it should never be modified by the
   client.  In practice, the selector string is often a pathname or
   other file selector used by the server to locate the item desired.
   The next two tab delimited fields denote the domain-name of the host
   that has this document (or directory), and the port at which to
   connect.  If there are yet other tab delimited fields, the basic
   Gopher client should ignore them.  A CR LF denotes the end of the
   item.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 4]
RFC 1436
Gopher                       March 1993
In the example, line 1 describes a document the user will see as
   "About internet Gopher".  To retrieve this document, the client
   software must send the retrieval string: "Stuff:About us" to
   rawBits.micro.umn.edu at port 70.  If the client does this, the
   server will respond with the contents of the document, terminated by
   a period on a line by itself.  A client might present the user with a
   view of the world something like the following list of items:

      About Internet Gopher
      Around the University of Minnesota...
      Microcomputer News & Prices...
      Courses, Schedules, Calendars...
      Student-Staff Directories...
      Departmental Publications...

   In this case, directories are displayed with an ellipsis and files
   are displayed without any.  However, depending on the platform the
   client is written for and the author's taste, item types could be
   denoted by other text tags or by icons.  For example, the UNIX
   curses-based client displays directories with a slash (/) following
   the name; Macintosh clients display directories alongside an icon of
   a folder.

   The user does not know or care that the items up for selection may
   reside on many different machines anywhere on the Internet.

   Suppose the user selects the line "Microcomputer News & Prices...".
   This appears to be a directory, and so the user expects to see
   contents of the directory upon request that it be fetched.  The
   following lines illustrate the ensuing client-server interaction:

    Client:           (Connects to pserver.bookstore.umn.edu at port 70)
    Server:           (Accepts connection but says nothing)
    Client: Prices/   (Sends the magic string terminated by CRLF)
    Server:           (Sends a series of lines, each ending with CR LF)
    0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70
    0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70
    0IBM PricesFPrices/IckFpserver.bookstore.umn.eduF70
    0Printer & Peripheral PricesFPrices/PPPFpserver.bookstore.umn.eduF70
                      (.....etc.....)
    .                 (Period on a line by itself)
                      (Server closes connection)
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 5]
RFC 1436
Gopher                       March 1993
3
. More details
3.1
Locating services
Documents (or other services that may be viewed ultimately as
   documents, such as a student-staff phonebook) are linked to the
   machine they are on by the trio of selector string, machine domain-
   name, and IP port.  It is assumed that there will be one well-known
   top-level or root server for an institution or campus.  The
   information on this server may be duplicated by one or more other
   servers to avoid a single point of failure and to spread the load
   over several servers.  Departments that wish to put up their own
   departmental servers need to register the machine name and port with
   the administrators of the top-level Gopher server, much the same way
   as they register a machine name with the campus domain-name server.
   An entry which points to the departmental server will then be made at
   the top level server.  This ensures that users will be able to
   navigate their way down what amounts to a virtual hierarchical file
   system with a well known root to any campus server if they desire.

   Note that there is no requirement that a department register
   secondary servers with the central top-level server; they may just
   place a link to the secondary servers in their own primary servers.
   They may indeed place links to any servers they desire in their own
   server, thus creating a customized view of thethe Gopher information
   universe; links can of course point back at the top-level server.
   The virtual (networked) file system is therefore an arbitrary graph
   structure and not necessarily a rooted tree.  The top-level node is
   merely one convenient, well-known point of entry.  A set of Gopher
   servers linked in this manner may function as a campus-wide
   information system.

   Servers may of course point links at other than secondary servers.
   Indeed servers may point at other servers offering useful services
   anywhere on the internet.  Viewed in this manner, Gopher can be seen
   as an Internet-wide information system.
3.2
Server portability and naming
It is recommended that all registered servers have alias names
   (domain name system CNAME) that are used by Gopher clients to locate
   them.  Links to these servers should use these alias names rather
   than the primary names.  If information needs to be moved from one
   machine to another, a simple change of domain name system alias
   (CNAME) allows this to occur without any reconfiguration of clients
   in the field.  In short, the domain name system may be used to re-map
   a server to a new address.  There is nothing to prevent secondary
   servers or services from running on otherwise named servers or ports
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 6]
RFC 1436
Gopher                       March 1993
other than 70, however these should be reachable via a primary
   server.
3.3
Contacting server administrators
It is recommended that every server administrator have a document
   called something like: "About Bogus University's Gopher server" as
   the first item in their server's top level directory.  In this
   document should be a short description of what the server holds, as
   well as name, address, phone, and an e-mail address of the person who
   administers the server.  This provides a way for users to get word to
   the administrator of a server that has inaccurate information or is
   not running correctly.  It is also recommended that administrators
   place the date of last update in files for which such information
   matters to the users.
3.4
Modular addition of services
The first character of each line in a server-supplied directory
   listing indicates whether the item is a file (character '0'), a
   directory (character '1'), or a search (character '7').  This is the
   base set of item types in the Gopher protocol.  It is desirable for
   clients to be able to use different services and speak different
   protocols (simple ones such as finger; others such as CSO phonebook
   service, or Telnet, or X.500 directory service) as needs dictate.
   CSO phonebook service is a client/server phonebook system typically
   used at Universities to publish names, e-mail addresses, and so on.
   The CSO phonebook software was developed at the University of
   Illinois and is also sometimes refered to as ph or qi.  For example,
   if a server-supplied directory listing marks a certain item with type
   character '2', then it means that to use this item, the client must
   speak the CSO protocol.  This removes the need to be able to
   anticipate all future needs and hard-wire them in the basic Internet
   Gopher protocol; it keeps the basic protocol extremely simple.  In
   spite of this simplicity, the scheme has the capability to expand and
   change with the times by adding an agreed upon type-character for a
   new service.  This also allows the client implementations to evolve
   in a modular fashion, simply by dropping in a module (or launching a
   new process) for some new service.  The servers for the new service
   of course have to know nothing about Internet Gopher; they can just
   be off-the shelf CSO, X.500, or other servers.  We do not however,
   encourage arbitrary or machine-specific proliferation of service
   types in the basic Gopher protocol.

   On the other hand, subsets of other document retrieval schemes may be
   mapped onto the Gopher protocol by means of "gateway-servers".
   Examples of such servers include Gopher-to-FTP gateways, Gopher-to-
   archie gateways, Gopher-to-WAIS gateways, etc.  There are a number of
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 7]
RFC 1436
Gopher                       March 1993
advantages of such mechanisms. First, a relatively powerful server
   machine inherits both the intelligence and work, rather than the more
   modest, inexpensive desktop system that typically runs client
   software or basic server software.  Equally important, clients do not
   have to be modified to take advantage of a new resource.
3.5
Building clients
A client simply sends the retrieval string to a server if it wants to
   retrieve a document or view the contents of a directory.  Of course,
   each host may have pointers to other hosts, resulting in a "graph"
   (not necessarily a rooted tree) of hosts.  The client software may
   save (or rather "stack") the locations that it has visited in search
   of a document.  The user could therefore back out of the current
   location by unwinding the stack.  Alternatively, a client with
   multiple-window capability might just be able to display more than
   one directory or document at the same time.

   A smart client could cache the contents of visited directories
   (rather than just the directory's item descriptor), thus avoiding
   network transactions if the information has been previously
   retrieved.

   If a client does not understand what a say, type 'B' item (not a core
   item) is, then it may simply ignore the item in the directory
   listing; the user never even has to see it.  Alternatively, the item
   could be displayed as an unknown type.

   Top-level or primary servers for a campus are likely to get more
   traffic than secondary servers, and it would be less tolerable for
   such primary servers to be down for any long time.  So it makes sense
   to "clone" such important servers and construct clients that can
   randomly choose between two such equivalent primary servers when they
   first connect (to balance server load), moving to one if the other
   seems to be down.  In fact, smart client implementations do this
   clone server and load balancing.  Alternatively, it may make sense to
   have the domain name system return one of a set of redundant of
   server's IP address to load balance betwen redundant sets of
   important servers.
3.6
Building ordinary internet Gopher servers
The retrieval string sent to the server might be a path to a file or
   directory.  It might be the name of a script, an application or even
   a query that generates the document or directory returned.  The basic
   server uses the string it gets up to but not including a CR-LF or a
   TAB, whichever comes first.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 8]
RFC 1436
Gopher                       March 1993
All intelligence is carried by the server implementation rather than
   the protocol.  What you build into more exotic servers is up to you.
   Server implementations may grow as needs dictate and time allows.
3.7
Special purpose servers
There are two special server types (beyond the normal Gopher server)
   also discussed below:

      1.  A server directory listing can point at a CSO nameserver (the
      server returns a type character of '2') to allow a campus
      student-staff phonebook lookup service.  This may show up on the
      user's list of choices, perhaps preceded by the icon of a phone-
      book.  If this item is selected, the client software must resort
      to a pure CSO nameserver protocol when it connects to the
      appropriate host.

      2.  A server can also point at a "search server" (returns a first
      character of '7').  Such servers may implement campus network (or
      subnet) wide searching capability.  The most common search servers
      maintain full-text indexes on the contents of text documents held
      by some subset of Gopher servers.  Such a "full-text search
      server" responds to client requests with a list of all documents
      that contain one or more words (the search criteria).  The client
      sends the server the selector string, a tab, and the search string
      (words to search for). If the selector string is empty, the client
      merely sends the search string.  The server returns the equivalent
      of a directory listing for documents matching the search criteria.
      Spaces between words are usually implied Boolean ANDs (although in
      different implementations or search types, this may not
      necessarily be true).

   The CSO addition exists for historical reasons: at time of design,
   the campus phone-book servers at the University of Minnesota used the
   CSO protocol and it seemed simplest to just engulf them.  The index-
   server is however very much a Gopher in spirit, albeit with a slight
   twist in the meaning of the selector-string.  Index servers are a
   natural place to incorperate gateways to WAIS and WHOIS services.
3.7.1
Building CSO-servers
A CSO Nameserver implementation for UNIX and associated documentation
   is available by anonymous ftp from uxa.cso.uiuc.edu.  We do not
   anticipate implementing it on other machines.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti         [Page 9]
RFC 1436
Gopher                       March 1993
3.7.2
Building full-text search servers
A full-text search server is a special-purpose server that knows
   about the Gopher scheme for retrieving documents.  These servers
   maintain a full-text index of the contents of plain text documents on
   Gopher servers in some specified domain.  A Gopher full-text search
   server was implemented using several NeXTstations because it was easy
   to take advantage of the full-text index/search engine built into the
   NeXT system software.  A search server for generic UNIX systems based
   on the public domain WAIS search engine, is also available and
   currently an optional part of the UNIX gopher server.  In addition,
   at least one implementation of the gopher server incorperates a
   gateway to WAIS servers by presenting the WAIS servers to gopherspace
   as full-text search servers.  The gopher<->WAIS gateway servers does
   the work of translating from gopher protocol to WAIS so unmodified
   gopher clients can access WAIS servers via the gateway server.

   By using several index servers (rather than a monolithic index
   server) indexes may be searched in parallel (although the client
   software is not aware of this).  While maintaining full-text indexes
   of documents distributed over many machines may seem a daunting task,
   the task can be broken into smaller pieces (update only a portion of
   the indexes, search several partial indexes in parallel) so that it
   is manageable.  By spreading this task over several small, cheap (and
   fast) workstations it is possible to take advantage of fine-grain
   parallelism.  Again, the client software is not aware of this. Client
   software only needs to know that it can send a search string to an
   index server and will receive a list of documents that contain the
   words in the search string.
3.8
Item type characters
The client software decides what items are available by looking at
   the first character of each line in a directory listing.  Augmenting
   this list can extend the protocol.  A list of defined item-type
   characters follows:

   0   Item is a file
   1   Item is a directory
   2   Item is a CSO phone-book server
   3   Error
   4   Item is a BinHexed Macintosh file.
   5   Item is DOS binary archive of some sort.
       Client must read until the TCP connection closes.  Beware.
   6   Item is a UNIX uuencoded file.
   7   Item is an Index-Search server.
   8   Item points to a text-based telnet session.
   9   Item is a binary file!
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 10]
RFC 1436
Gopher                       March 1993
Client must read until the TCP connection closes.  Beware.
   +   Item is a redundant server
   T   Item points to a text-based tn3270 session.
   g   Item is a GIF format graphics file.
   I   Item is some kind of image file.  Client decides how to display.

   Characters '0' through 'Z' are reserved.  Local experiments should
   use other characters.  Machine-specific extensions are not
   encouraged.  Note that for type 5 or type 9 the client must be
   prepared to read until the connection closes.  There will be no
   period at the end of the file; the contents of these files are binary
   and the client must decide what to do with them based perhaps on the
   .xxx extension.
3.9
User display strings and server selector strings
User display strings are intended to be displayed on a line on a
   typical screen for a user's viewing pleasure.  While many screens can
   accommodate 80 character lines, some space is needed to display a tag
   of some sort to tell the user what sort of item this is.  Because of
   this, the user display string should be kept under 70 characters in
   length.  Clients may truncate to a length convenient to them.
4
.   Simplicity is intentional
As far as possible we desire any new features to be carried as new
   protocols that will be hidden behind new document-types.  The
   internet Gopher philosophy is:

      (a) Intelligence is held by the server.  Clients have the option
      of being able to access new document types (different, other types
      of servers) by simply recognizing the document-type character.
      Further intelligence to be borne by the protocol should be
      minimized.

      (b) The well-tempered server ought to send "text" (unless a file
      must be transferred as raw binary).  Should this text include
      tabs, formfeeds, frufru?  Probably not, but rude servers will
      probably send them anyway.  Publishers of documents should be
      given simple tools (filters) that will alert them if there are any
      funny characters in the documents they wish to publish, and give
      them the opportunity to strip the questionable characters out; the
      publisher may well refuse.

      (c) The well-tempered client should do something reasonable with
      funny characters received in text; filter them out, leave them in,
      whatever.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 11]
RFC 1436
Gopher                       March 1993
Appendix

   Paul's NQBNF (Not Quite BNF) for the Gopher Protocol.

   Note:  This is modified BNF (as used by the Pascal people) with a few
          English modifiers thrown in.  Stuff enclosed in '{}' can be
          repeated zero or more times.  Stuff in '[]' denotes a set of
          items.  The '-' operator denotes set subtraction.

Directory Entity

CR-LF     ::= ASCII Carriage Return Character followed by Line Feed
              character.

Tab       ::= ASCII Tab character.

NUL       ::= ASCII NUL character.

UNASCII   ::= ASCII - [Tab CR-LF NUL].

Lastline  ::= '.'CR-LF.

TextBlock ::= Block of ASCII text not containing Lastline pattern.

Type      ::= UNASCII.

RedType   ::= '+'.

User_Name ::= {UNASCII}.

Selector  ::= {UNASCII}.

Host      ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}.

Note: This is a Fully Qualified Domain Name as defined in
RFC 1034
.
      (e.g., gopher.micro.umn.edu)  Hosts that have a CR-LF
      TAB or NUL in their name get what they deserve.

Digit     ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' .

DigitSeq  ::= digit {digit}.

Port      ::= DigitSeq.

Note: Port corresponds the the TCP Port Number, its value should
      be in the range [0..65535]; port 70 is officially assigned
      to gopher.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 12]
RFC 1436
Gopher                       March 1993
DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF
          {RedType User_Name Tab Selector Tab Host Tab Port CR-LF}

Notes:

   It is *highly* recommended that the User_Name field contain only
   printable characters, since many different clients will be using
   it.  However if eight bit characters are used, the characters
   should conform with the ISO Latin1 Character Set.  The length of
   the User displayable line should be less than 70 Characters; longer
   lines may not fit across some screens.

   The Selector string should be no longer than 255 characters.

Menu Entity

Menu      ::= {DirEntity} Lastline.

Menu Transaction  (Type 1 item)

C: Opens Connection
S: Accepts Connection
C: Sends Selector String
S: Sends Menu Entity

   Connection is closed by either client or server (typically server).

Textfile Entity

TextFile  ::= {TextBlock} Lastline

Note:  Lines beginning with periods must be prepended with an extra
     period to ensure that the transmission is not terminated early.
     The client should strip extra periods at the beginning of the line.

TextFile Transaction (Type 0 item)

C: Opens Connection.
S: Accepts connection
C: Sends Selector String.
S: Sends TextFile Entity.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 13]
RFC 1436
Gopher                       March 1993
Connection is closed by either client or server (typically server).

Note:  The client should be prepared for the server closing the
       connection without sending the Lastline.  This allows the
       client to use fingerd servers.

Full-Text Search Transaction (Type 7 item)

Word      ::= {UNASCII - ' '}
BoolOp ::= 'and' | 'or' | 'not' | SPACE
SearchStr ::= Word {{SPACE BoolOp} SPACE Word}

C: Opens Connection.
C: Sends Selector String, Tab, Search String.
S: Sends Menu Entity.

Note:  In absence of 'and', 'or', or 'not' operators, a SPACE is
       regarded as an implied 'and' operator.  Expression is evaluated
       left to right.  Further, not all search engines or search
       gateways currently implemented have the boolean operators
       implemented.

Binary file Transaction (Type 9 or 5 item)

C: Opens Connection.
S: Accepts connection
C: Sends Selector String.
S: Sends a binary file and closes connection when done.

Syntactic Meaning for Directory Entities

The client should interpret the type field as follows:
0
The item is a TextFile Entity.
Client should use a TextFile Transaction.
1
The item is a Menu Entity.
Client should use a Menu Transaction.
2
The information applies to a CSO phone book entity.
Client should talk CSO protocol.
3
Signals an error condition.
4
Item is a Macintosh file encoded in BINHEX format
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 14]
RFC 1436
Gopher                       March 1993
5
Item is PC-DOS binary file of some sort.
Client gets to decide.
6
Item is a uuencoded file.
7
The information applies to a Index Server.
Client should use a FullText Search transaction.
8
The information applies to a Telnet session.
Connect to given host at given port. The name to login as at this
host is in the selector string.
9
Item is a binary file.
Client must decide what to do with it.

+   The information applies to a duplicated server.  The information
    contained within is a duplicate of the primary server.  The primary
    server is defined as the last DirEntity that is has a non-plus
    "Type" field.  The client should use the transaction as defined by
    the primary server Type field.

g   Item is a GIF graphic file.

I   Item is some kind of image file.  Client gets to decide.

T   The information applies to a tn3270 based telnet session.
    Connect to given host at given port. The name to login as at this
    host is in the selector string.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Farhad Anklesaria
   Computer and Information Services, University of Minnesota
   Room 152 Shepherd Labs
   100 Union Street SE
   Minneapolis, MN 55455

   Phone: (612) 625 1300
   EMail: fxa@boombox.micro.umn.edu
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 15]
RFC 1436
Gopher                       March 1993
Mark McCahill
   Computer and Information Services, University of Minnesota
   Room 152 Shepherd Labs
   100 Union Street SE
   Minneapolis, MN 55455

   Phone: (612) 625 1300
   EMail: mpm@boombox.micro.umn.edu

   Paul Lindner
   Computer and Information Services, University of Minnesota
   Room 152 Shepherd Labs
   100 Union Street SE
   Minneapolis, MN 55455

   Phone: (612) 625 1300
   EMail: lindner@boombox.micro.umn.edu

   David Johnson
   Computer and Information Services, University of Minnesota
   Room 152 Shepherd Labs
   100 Union Street SE
   Minneapolis, MN 55455

   Phone: (612) 625 1300
   EMail: dmj@boombox.micro.umn.edu

   Daniel Torrey
   Computer and Information Services, University of Minnesota
   Room 152 Shepherd Labs
   100 Union Street SE
   Minneapolis, MN 55455

   Phone: (612) 625 1300
   EMail: daniel@boombox.micro.umn.edu

   Bob Alberti
   Computer and Information Services, University of Minnesota
   Room 152 Shepherd Labs
   100 Union Street SE
   Minneapolis, MN 55455

   Phone: (612) 625 1300
   EMail: alberti@boombox.micro.umn.edu

Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti        [Page 16]
RFC
1436
: The Internet Gopher Protocol (a distributed document search and retrieval protocol)
Informational


Implement Policy -  - ICANN

Implement Policy - - ICANN
Skip to main content
Search ICANN.org
Log In
Sign Up
Get Started
About ICANN
ICANN for Beginners
Fellowship Program
NextGen@ICANN Program
History
News and Media
Announcements
Blog
Media Resources
Press Releases
Global Newsletters
ICANN News Subscriptions
Regional Reports
Policy
Develop Policy
Operational Design Phase (ODP)
Implement Policy
Community Participation Guidelines
Public Comment
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
About Public Comment
Other Public Consultations
Resources
Board Activities and Meetings
Accountability Mechanisms
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
Contractual Compliance
Domain Name Security Threats
Privacy and Proxy Services
Government Engagement
Careers
Complaints Office
I Need Help
ICANN 25th Anniversary Photo Mosaic
Community
Engagement Calendar
Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Quicklinks
Board Activities and Meetings
Data Protection and Privacy
Domain Name Registrants
Engagement Calendar
IANA Services
ICANN Acronyms and Terms
ICANN Grant Program
New gTLD Program
Public Technical Identifiers (PTI)
Open Data
Question About A Domain Name?
Technology @ ICANN
WSIS+20 Outreach Network
Resources
About ICANN
Academic Engagement
Acronyms and Terms
Courses and Learning
ICANN for Beginners
Participate
What ICANN Does
Effect on the Internet
What's Going On Now
How to Participate
Fellowship Program
Committee
Terms & Conditions
NextGen@ICANN Program
President's Corner
ICANN Management Organization Chart
Staff
Careers
In Focus
ICANN Response Planning Framework
DNSSEC
Standards
IANA DNSSEC Root Information
TLD DNSSEC Report
Root Deployment
Deployment Graph
Tools
Training
Key Ceremony
News
Blog Posts
Presentations
Related Sites
GNSO Improvements
Travel Support
Media Resources
ICANN News
About ICANN
Subscribe and Follow
Contacts
Board Activities and Meetings
Accountability
Accountability Mechanisms
Reconsideration
Independent Review Process
Updating the IRP
Ombuds
About the Ombuds Office
Contact the Ombuds Office
Ombuds Office Services
Complaints About Unfairness
Complaints About Harassment
Collaborative Conflict Resolution
Request for Reconsideration
Resources for Community Members
Ombuds Office Accountability
Ombud's Blogs
Empowered Community
Empowered Community Administration
Empowered Community Administration Mailing List
Empowered Community Correspondence
Document Disclosure
Reviews
Organizational Reviews
ALAC
ASO
Board
ccNSO
GNSO
Nominating Committee
RSSAC
SSAC
Technical Liaison Group
Specific Reviews
Accountability & Transparency
Registration Directory Service
Security, Stability, and Resiliency
Competition, Consumer Trust & Consumer Choice
CCT Metrics
Expected Standards of Behavior
Employee Practices and Resources
Enhancing ICANN Accountability – Work Stream 2 Implementation
Governance
Governance Documents
Evolving ICANN’s Multistakeholder Model
Agreements
NTIA IANA Functions' Stewardship Transition
Call for Public Input: Draft Process to Develop the Proposal (8 April-8 May 2014
Process to Develop the Proposal and Next Steps
Registry
Archive
Affirmation of Commitments
AOC Tracking
ccTLD
Partnership Memorandums of Understanding
Registrar
Archive
Annual Reports
Financials
Financial Reports
Policies, Guidelines and Procedures
Annual Disclosure of Payments to Suppliers
Lobbying Disclosures & Contribution Reports
Planning
Strategic Plan
ICANN Strategic Plan for FY26-30
ICANN's Annual Strategy Review Program
ICANN Strategic Plan for FY21-25
Strategic Outlook Trends Program
ICANN Strategic Plan for FY16-20
Operating Plan
Presentations
RFPs
Litigation
Newsletter
Correspondence
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Quarterly Reports
Groups
2023 ICANN CEO Search Committee
RSSAC
Charter
SSAC
GAC
At-Large
ASO
ccNSO
GNSO
Technical Liaison Group
Technical Experts Group (TEG)
NomCom
Past NomComs
Customer Standing Committee
Root Zone Evaluation Review Committee (RZERC)
Business
Civil Society
Complaints Office
Complaints Report
Domain Name System Abuse
Contractual Compliance
About
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
Archive
Contractual Compliance Metrics
Blogs
Contractual Compliance Audit Program
Notice of Bankruptcy, Convictions and Security Breaches
Contractual Compliance Reports
Audit Reports
Enforcement of DNS Abuse Mitigation Requirements: Periodic Reviews
Contractual Compliance Monthly Reports
gTLD Registry Compliance
Accredited Registrar Compliance
General Questions
Outreach
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
About Domain Names
ICANN Policies
Registration Data Policies
WHOIS and Registration Data Directory Services
The Domain Name Registration Process
Using Domain Name Registration Data
Keeping Registration Data Accurate
Access and the Evolution of the WHOIS System
Domain Name Industry
Registering Domain Names
Managing Domain Names
Contact Information and WDRP
Securely Managing Your Domain Name
Transferring Domain Names
Renewing Domain Names
Rights and Responsibilities
Spam, Phishing, and Website Content
Trademark Infringement
GDS Metrics
Identifier Systems Security, Stability and Resiliency (OCTO-SSR)
ccTLDs
Background Materials
Agreements
Delegation
Root Zone Database
Model MOU
Workshops
ICANN and ISO
Internationalized Domain Names
Root Zone Label Generation Rules (LGR)
Generation Panel Update
Maximal Starting Repertoire
Proposals for Root Zone Label Generation Ruleset
IDN Variant TLD Implementation
LGR Toolset
IDN ccTLD Fast Track
IDN Implementation Guidelines
Second-Level LGR Reference
Resources
Announcements and Blogs Posts
New gTLD Program
Universal Acceptance Initiative
Make your systems UA-ready
UA Training
UA Day
UA Readiness Evaluations
UA Initiatives
Announcements and Blogs Posts
Policy
Policy Mission
Policy Staff Goals
Presentations
Global Addressing
IPv6 Allocation
ASN Allocation
Post Exhaustion IPv4 Allocation
New RIRs Criteria
Review Procedures
Policy Updates
Operational Design Phase (ODP)
Implementation
Public Comment
Open
Upcoming
Archive
Root Zone KSK Rollover
Technical Functions
Tech Day Archive
ICANN Locations
Report Security Issues
PGP Keys
Certificate Authority
Registry Liaison
Ombudsman
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Charter Eligibility Dispute Resolution Policy
Providers
Rules
Eligibility Requirements Dispute Resolution Policy
Providers
Rules
Intellectual Property Defensive Registration Challenge Policy
Providers
Rules
Qualification Challenge Policy
Providers
Rules
Restrictions Dispute Resolution Policy
Providers
Rules
Transfer Dispute Resolution Policy
Providers
Uniform Domain Name Dispute Resolution Policy
Policy Document
Providers
Provider Approval Process
Rules
Principal Documents
Proceedings
Historical Documents
Timeline
Name Collision
Registrar Problems
Whois Data Correction
Independent Review Process
Request for Reconsideration
Document
Implementing Policy at ICANN
ICANN coordinates the Internet's unique identifiers – domain names and IP addresses – across the world and defines policies for how these identifiers should run (
learn more
).
Policies for generic top-level domains (gTLDs) are developed within the Generic Names Supporting Organization's (GNSO)
Policy Development Processes
(PDPs). Once the policy recommendations emerging from these PDPs are adopted by the ICANN Board, ICANN's Global Domains & Strategy (GDS) implements them according to guidelines established in the
Consensus Policy Implementation Framework (v2018)
(CPIF).
On this page, you will find information about:
How Policy is implemented
Current implementation projects
Policy Status Reports
Policy Effective Dates
Resources
How is Policy Implemented?
The CPIF is a five-stage process designed to make implementations predictable and transparent. During each implementation project, GDS staff consults with the wider community by:
Assembling a team of volunteer experts—an Implementation Review Team (IRT), in the relevant subject matter to provide advice and support.
Conducting public comment periods on proposed implementation plans and/or Consensus Policies.
Consolidated Scorecards
ICANN org publishes this Consolidated Scorecard periodically to help the community track work through different phases. This resource brings together information about community-developed policy and other outcomes in one place.
For status updates on community policy development, please view the scorecards
here
.
Implementation Projects In Progress
Implementation Project
Expected Completion Date
Expedited Policy Development Process for Internationalized Domain Names
2026
IGO-INGO Curative Rights
2026
Privacy and Proxy Services Accreditation
2027
Rights Protection Mechanisms Implementation
2026
Implementation Projects In Queue
Project
ccPDP3 Policy Implementation
EPDP Phase 2A on the Temporary Specification for gTLD Registration Data
GNSO Internationalized Domain Names EPDP Phase 2
Transfer Policy Review
Translation and Transliteration of Contact Information
Policy Recommendations Pending Board Action
Project
ccNSO Policy Development Process 4 (ccPDP4) (De-) selection of IDN ccTLD Strings
Policy Development Processes
The following are GNSO PDPs currently in progress which may result in consensus policy recommendations. If the ICANN Board adopts these policy recommendations, they will become implementation projects to be carried out by GDS staff:
Project
Expected Completion Date
Latin Script Diacritics Policy Development Process
2026
DNS Abuse Mitigation Policy Development Process
1
2027
Pre-Meeting Briefings
For the latest Policy Research and Stakeholder Programs (PRSP) Pre-ICANN Update Briefing, please view the briefing
here
.
Policy Effective Dates
Policies developed within the GNSO and implemented by GDS affect many companies and organizations in the domain name industry. ICANN has committed to simplifying implementation via the
Policy Change Calendar Initiative
[PDF, 166 KB], which aims to provide contracted parties with a consistent, predictable timetable for updating their operations to meet new policy requirements.
Since May 2015, GDS has worked to bundle the announcement and effective dates for related policies. Policies within a bundle are announced together, which triggers a window of at least six months for contracted parties to update their operations to ensure compliance with the new policies. Effective dates are the same for all policies in a bundle, which are noted in the announcement.
Policy Status Reports
Per the mandate of the "Support and Review" phase of the CPIF, ICANN org and the GNSO Council periodically produce and review Policy Status Reports in order to assess the effectiveness and impact of an implemented Consensus Policy.
Policy Status Report: Expired Domain Deletion Policy and Expired Registration Recovery Policy
(August 2025)
Policy Status Report: Policy Status Report: GNSO Policy & Implementation Working Group Recommendations
(February 7, 2025)
Policy Status Report: Uniform Domain Name Dispute Resolution Policy (UDRP)
(July 13, 2022)
Policy Status Report: Inter-Registrar Transfer Policy
(March 2019)
Resources
Adopted Consensus Policies
Repository and archive of implementation documents
Contact Information
For questions or comments please contact:
[email protected]
ICANN is not responsible for profile content or verification of user details.
YouTube
Twitter
LinkedIn
Flickr
Facebook
Newsletters
Community Wiki
ICANN Blog
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability And Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Request for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers.
Privacy Policy
Terms of Service
Cookies Policy
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."