Automatic Configuration of Email, Calendar, and Contact Server Settings

3.1. Server Requirements Summary

The following is a non-normative, high-level summary of what a server operator needs to implement.¶

• Publish a JSON configuration document at a well-known HTTPS URI, listing the domain's supported protocols and their server endpoints.¶
• Publish DNS TXT records containing a digest of that configuration document, so user agents can verify its integrity.¶
• Accept the user's full email address as the username on all servers listed in the configuration.¶
• Optionally, support the OAuth Profile for Open Public Clients to enable OAuth-based authentication.¶

3.2. User Agent Requirements Summary

The following is a non-normative, high-level summary of what a user agent needs to implement.¶

• Ability to construct the well-known URI from a user's email address and retrieve the JSON configuration document over HTTPS.¶
• Ability to validate the configuration document's integrity by comparing its digest against a DNS TXT record.¶
• Ability to connect to each server listed in the configuration and retrieve its supported authentication mechanisms.¶
• User interface to present the server hostnames for the user to confirm before any credentials are entered.¶
• Support for OAuth Profile for Open Public Clients and/or password-based authentication, to complete account setup.¶

4.1. Example

The following example demonstrates a typical JSON configuration:¶

========== NOTE: '\' line wrapping per RFC 8792 ===========

{
    "protocols": {
        "jmap": {
            "url": "https://jmap.example.com/session"
        },
        "imap": {
            "host": "imap.example.com"
        },
        "pop3": {
            "host": "pop3.example.com"
        },
        "submit": {
            "host": "smtp.example.com"
        },
        "caldav": {
            "url": "https://sync.example.com/.well-known/caldav"
        },
        "carddav": {
            "url": "https://sync.example.com/.well-known/carddav"
        }
    },
    "authentication": {
        "oauth-public": {
            "issuer": "https://auth.example.com"
        },
        "password": true
    },
    "info": {
        "provider": {
            "name": "Example Provider Name",
            "shortName": "Example",
            "logo": [
                {
                    "url": "https://www.example.com/logo.svg",
                    "content-type": "image/svg+xml"
                }
            ]
        },
        "help": {
            "documentation": "https://help.example.com/howto/\
                set-up-your-mail-app.html",
            "developer": "https://developer.example.com/\
                client-apps/",
            "contact": ["mailto:it@example.com"]
        }
    }
}

4.2. Protocols

The protocols object specifies all protocols that the domain supports and identifies the server endpoint for each protocol.¶

For the following HTTP-based protocols:¶

• JMAP defined in [RFC8620],¶
• CalDAV defined in [RFC4791],¶
• CardDAV defined in [RFC6352], and¶
• WebDAV defined in [RFC4918]¶

each protocol entry MUST include a url value containing a URL with the https scheme. A server MAY answer a request for this URL with a redirect (see Section 7.5); the URL reached after all redirects have been followed MUST specify an endpoint that serves the corresponding protocol. The server MUST use the default port 443 for HTTPS, and the URL MUST NOT include an explicit port number.¶

The webdav protocol entry describes a WebDAV service used for file sharing, as distinct from the calendar and contact services described by the caldav and carddav entries.¶

For the WebDAV-based protocols CalDAV, CardDAV, and WebDAV, the url value serves two purposes: the user agent uses it to probe for supported authentication schemes (see Section 5.4.2), and, once authenticated, it uses it as the base URL for the protocol itself. It is therefore not sufficient for the url to be any resource that merely triggers authentication; it MUST be a URL that the user agent can use as the initial "context path" for the bootstrapping procedure in Section 6 of [RFC6764]. Specifically, the url MUST be either:¶

1. the protocol-specific .well-known URI defined in Section 5 of [RFC6764] (that is, https://example.com/.well-known/caldav for CalDAV and https://example.com/.well-known/carddav for CardDAV), which redirects to such a context path; or¶
2. the context path itself, that is, a WebDAV resource that responds to a PROPFIND request (Section 9.1 of [RFC4918]).¶

For CalDAV and CardDAV, providers SHOULD publish the protocol-specific .well-known URI (form 1). Section 5 of [RFC6764] already requires servers to support these URIs and to redirect requests for them to the actual context path, and requires user agents to follow those redirects, so form 1 is the most broadly interoperable choice. It also lets a provider change the context path, including on a per-user basis, without republishing the configuration document and updating its DNS digest (Section 5.2.2).¶

[RFC6764] does not define a .well-known URI for WebDAV as defined in [RFC4918], and no such URI is registered in the "Well-Known URIs" registry. The url of a webdav protocol entry MUST therefore be the context path (form 2).¶

The url MUST NOT be a bare origin, nor any other URL that neither serves the protocol itself nor redirects to a resource that does, and that would require the user agent to derive the context path on its own. Note that a server MUST NOT locate the actual service endpoint at the .well-known URI (Section 5 of [RFC6764]); form 1 therefore always involves at least one redirect.¶

The user agent sends its PROPFIND probe to this url and follows any redirect subject to the constraints in Section 7.5. The URL reached after all redirects have been followed is the context path that the user agent uses for subsequent protocol operations; the user agent is not required to derive .well-known URIs itself. A server MAY require authentication before it issues the redirect, as described in Section 5 of [RFC6764]; such a response also carries the WWW-Authenticate header fields that the user agent is probing for (see Section 5.4.2). Where the OAuth profile in [OAuthPublic] calls for a protected-resource identifier, that identifier is the context path reached after all redirects have been followed, not the url as published in the configuration.¶

Hostnames in URLs MUST support Internationalized Domain Names (IDNs) as defined in [RFC5890] and [RFC5891]. Service providers MAY use either Unicode labels (u-labels) or ASCII Compatible Encoding labels (a-labels) in their configuration. User agents MUST support both forms and handle the conversion between them as specified in [RFC5891].¶

Example:¶

"jmap": {
    "url": "https://jmap.example.com/session"
}

For the following text-based protocols:¶

• IMAP defined in [RFC9051],¶
• POP3 defined in [RFC1939],¶
• Submission defined in [RFC6409], and¶
• ManageSieve defined in [RFC5804]¶

each protocol entry MUST include a host value specifying the hostname of the server that provides the corresponding protocol. The service MUST be available on the default port for that protocol, with the connection secured using TLS from the start of the connection, also known as "direct TLS" or "implicit TLS". Section 5.4.3 goes into details about TLS and which ports to use.¶

Hostnames MUST support Internationalized Domain Names (IDNs) as defined in [RFC5890] and [RFC5891]. Service providers MAY use either Unicode labels (u-labels) or ASCII Compatible Encoding labels (a-labels) in their configuration. User agents MUST support both forms and handle the conversion between them as specified in [RFC5891].¶

Example:¶

"imap": {
    "host": "imap.mail.example.com"
}

4.3. Authentication

The authentication object specifies which authentication mechanisms the provider supports.¶

The authentication object itself is optional, but providers SHOULD include it. If it is absent, the configuration makes no statement about the authentication mechanisms that the provider supports, and the user agent has to determine them solely by probing each server of interest as described in Section 5.4.¶

If the authentication object is present, it MUST include the password value. This value indicates whether the provider supports username and password authentication. A provider that supports OAuth but not password-based authentication therefore publishes "password": false.¶

The nested oauth-public object contains a single issuer value that specifies the authorization server's issuer identifier as defined in [RFC8414]. This value is a URL that uses the https scheme and has no query or fragment components. User agents can use this identifier for authentication via [OAuthPublic]. The presence of the oauth-public object indicates that the provider supports OAuth; its absence indicates that it does not.¶

The contents of the authentication object describe the provider as a whole. Individual servers can differ, so a user agent still needs to probe each server that it intends to use, as described in Section 5.4.¶

4.4. Informational

The info object contains information that user agents can present to users. The only required field is info/provider/name, which SHOULD clearly identify the provider to the user. The optional info/provider/shortName provides a shorter version of name.¶

The info/provider/logo array can contain one or more entries pointing to the provider's logo images. User agents can use these to display the provider's logo to users.¶

The info/help/documentation field provides a URL that can be presented to users for additional information about the provider. The info/help/developer field contains a URL with information specifically for user agent developers. The info/help/contact array lists URLs, such as mailto URLs, that user agent developers can use to contact the provider. As described in Section 4.4.2, these URLs are not intended for users, and user agents MUST NOT display them.¶

A minimal info example:¶

"info": {
    "provider": {
        "name": "Example Provider Name"
    }
}

5.1. Email Address

During the initial configuration process, the user agent requests the user's email address. User agents SHOULD accept any valid mailbox format as specified in Section 3.4 of [RFC5322].¶

5.2. Configuration Source

After the user provides their email address, the user agent extracts the domain part of the user's email address according to Section 3.4.1 of [RFC5322]. For example:¶

This domain is then used to retrieve the JSON configuration resource using well-known URIs with DNS-based digest validation.¶

========== NOTE: '\' line wrapping per RFC 8792 ===========

https://ua-auto-config.{domain}/\
  .well-known/user-agent-configuration.json

========== NOTE: '\' line wrapping per RFC 8792 ===========

https://ua-auto-config.foo.example.com/\
  .well-known/user-agent-configuration.json

GET /.well-known/user-agent-configuration.json HTTP/1.1
host: ua-auto-config.foo.example.com
user-agent: curl/8.4.0
accept: application/json

HTTP/1.1 200 OK
server: nginx/1.25.3
date: Thu, 23 Oct 2025 10:30:00 GMT
content-type: application/json
content-length: 1184

{
    "protocols": {
        "jmap": {
...

config-record    = tag-spec *( *WSP ";" *WSP tag-spec ) *WSP [";"]

tag-spec         = version-tag / alg-tag / digest-tag / future-tag

version-tag      = "v" *WSP "=" *WSP "UAAC1"
alg-tag          = "a" *WSP "=" *WSP digest-algorithm
digest-algorithm = "sha256"
digest-tag       = "d" *WSP "=" *WSP 1*base64-char

future-tag       = 1*tag-name-char *WSP "=" *WSP 1*tag-value-char

tag-name-char    = ALPHA / DIGIT
tag-value-char   = %x21-3A / %x3C-7E ; Any visible ASCII char
                                     ; except semicolon

base64-char      = ALPHA / DIGIT / "+" / "/" / "="

5.3. Configuration JSON Validation

After successfully retrieving a configuration resource, user agents MUST validate that the configuration contains valid JSON syntax according to [RFC8259]. Additionally, user agents MUST validate the retrieved configuration against the JSON schema provided in Appendix A. If the JSON syntax is invalid, or if the configuration does not validate against that schema, user agents MUST ignore the configuration entirely and not use any portion of it.¶

User agents MUST process only the properties that they support and MUST ignore properties not specified in the schema. This requirement enables future extensions of the format without breaking existing user agent implementations.¶

5.4. Selecting Protocols and Authentication

After successfully retrieving and validating the configuration JSON, the user agent needs to determine:¶

• Which protocols to use¶
• Which authentication mechanism to employ¶

Both user agents and servers support multiple protocols. The user agent needs to decide which protocols to use and determine whether the protocols specified in the configuration are sufficient to proceed. This document does not provide recommendations regarding protocol preferences or minimum protocol requirements, as these decisions depend on the specific needs and implementation details of individual user agents.¶

The automatic configuration flow supports two distinct authentication types:¶

• Username and password-based authentication¶
• OAuth-based authentication¶

User agents can support one or both authentication methods. Similarly, servers for each protocol can support one or both methods. Additionally, the specific implementation details of authentication can vary between protocols.¶

User agents SHOULD probe each protocol and server of interest to determine compatible authentication methods. This probing process can influence the user agent's protocol selection and allows the user agent to verify server availability.¶

This document does not provide recommendations regarding protocol preferences. The user agent MUST make these decisions based on its needs.¶

If the user agent determines that it can use either password-based authentication or OAuth authentication, the user agent SHOULD prefer OAuth-based authentication.¶

{issuer}/.well-known/oauth-authorization-server

"oauth-public" : {
    "issuer" : "https://auth.example.com"
},

PROPFIND /dav/ HTTP/1.1
host: dav.example.com
depth: 0
content-type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:">
  <prop>
    <current-user-principal/>
  </prop>
</propfind>

GET /jmap/session HTTP/1.1
host: api.example.com
accept: application/json

HTTP/1.1 401 Unauthorized
www-authenticate: Bearer realm="api.example.com"

========== NOTE: '\' line wrapping per RFC 8792 ===========

HTTP/1.1 401 Unauthorized
www-authenticate: Digest realm="api.example.com", qop="auth", \
algorithm=SHA-256, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
opaque="5ccc069c403ebaf9f0171e9517f40e41"

========== NOTE: '\' line wrapping per RFC 8792 ===========

S: * OK [CAPABILITY IMAP4rev2 IMAP4rev1 SASL-IR AUTH=PLAIN \
AUTH=OAUTHBEARER] IMAP Server
C: A1 LOGOUT
S: * BYE IMAP Server logging out
S: A1 OK LOGOUT completed

S: 220 smtp.example.com ESMTP service ready
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-AUTH PLAIN LOGIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES
S: 250 8BITMIME
C: QUIT
S: 221 Bye

S: +OK pop.example.com POP3 server ready
C: CAPA
S: +OK List of capabilities follows
S: SASL PLAIN OAUTHBEARER
S: IMPLEMENTATION BlurdyBlurp POP3 server
S: .
C: QUIT
S: +OK POP3 server signing off (maildrop empty)

5.5. Confirming Server Names

Before any credentials are entered, the user agent SHOULD display to the user the hostnames of all servers that it intends to authenticate with, and request explicit confirmation. This list of server hostnames gives the user a chance to validate if they want to move ahead.¶

The user agent MAY choose to limit the hostnames to their registrable domains when displaying this list. Instead of displaying mail.example.com the user agent would display example.com, and instead of mail.example.co.uk it would display example.co.uk. Limiting the hostnames to their registrable domains helps users identify if this is the domain they intend to connect to or not.¶

At least the registrable domains of all involved hostnames MUST be displayed clearly and prominently. The user agent MUST NOT cut off parts of long registrable domains, to avoid spoofing. At least 63 characters of the registrable domain MUST be displayed.¶

If the user mistyped their email address in Section 5.1, letting the user confirm the server hostnames gives the user a chance to notice this.¶

When the user agent has followed an HTTP redirect while probing a server (see Section 5.4.2 and Section 7.5), the hostname it displays for that server MUST be the hostname reached after all redirects have been followed, not the hostname taken from the configuration. Otherwise the user could confirm a hostname that differs from the one the user agent ultimately authenticates with.¶

User agents can enhance the user experience by using the info section of the configuration (described in Section 4.4) to display the provider's name and logo during this configuration step.¶

Section 7.1 lists security considerations related to the user confirming these hostnames.¶

5.6. Username

For password-based authentication, the full addr-spec part of the email address MUST be used as the username. For example:¶

For OAuth Profile for Open Public Clients, the user agent MUST send this username as the login_hint in the authorization request URL.¶

The provider MUST ensure that any valid email address that the user might enter during setup is a valid username for all servers given in this configuration. This will require a mapping on the server level from email address to internal username. This mapping happens internally in the server and the user agent is not involved in this mapping.¶

5.7. Configuring OAuth

If the user agent and the provider both support OAuth Profile for Open Public Clients, and if the servers that the user agent wants to use support OAuth, the user agent can configure OAuth.¶

The authentication section in the JSON configuration described in Section 4.3 will let the user agent create a URL to retrieve the OAuth Authorization Server Metadata as described in Section 5.4.1. With this metadata, the user agent can then use [OAuthPublic] to configure OAuth.¶

Part of this will require opening the authorization request URL in an external browser, which is typically the user's default browser. The user agent SHOULD make it very apparent to the user which hostname is being used for the authorization request URL. The user agent SHOULD make the user confirm at least the registrable domain of the hostname of this URL. This is to minimize the risk of the user exposing their credentials to a third party.¶

As described in Section 5.5, the user agent SHOULD also confirm the server hostnames with the user. For OAuth authentication, the user agent SHOULD include the hostname of the authorization request URL in this list of hostnames.¶

5.8. Configuring Password-Based Authentication

If the user agent and provider both support password-based authentication, and if the servers that the user agent wants to use support password-based authentication, the user agent can configure itself to use these servers.¶

The user agent SHOULD at this point ask the user for the password for their account with the provider.¶

Once the user has entered their password, the user agent SHOULD validate that it is able to authenticate using the entered password with all servers that it is interested in. Only then would it save the new configuration.¶

7.1. Mistyped Domain Names

As part of the first step of the mechanism described in this document, the user enters their email address. If the user mistyped the domain part of their email address, and if the mistyped domain exists and supports the mechanism described in this document, the user could expose their credentials to the owner of that domain. An attacker could use this in an attempt to gain knowledge of the user's credentials.¶

As a result, user agents need to carefully design their user interface and user experience as to let the user know which domain is being used. It would make sense to display this very clearly to the user, before they enter any credentials.¶

The user agent would want to display a list of the registrable domains of all the servers that it intends to use. The user can then confirm these.¶

When the mechanism described in this document uses OAuth, it would make sense to ask the user to confirm the domains of the servers that will be used and additionally confirm the domains of¶

• the URL to retrieve the OAuth Authorization Server Metadata and/or¶
• the authorization request URL.¶

When asking the user to confirm these domains, it would make sense to only display the registrable domain of those domains. This would make it more difficult for an attacker to do URL obfuscation and use subdomain phishing.¶

When using a browser for OAuth, the user agent would want to display the registrable domain that the browser is currently displaying, and update this when redirects happen or new pages are loaded.¶

7.2. Attacker Controlled JSON Configuration

If an attacker can direct the user agent to use an attacker-controlled JSON configuration, the attacker would be able to direct the user to servers of the attacker's choosing.¶

The transport security requirements in Section 7.4 and the digest validation in Section 5.2.2 limit an attacker's ability to substitute a configuration in the first place. Presenting the server names for the user to confirm (Section 5.5), following the display guidance in Section 7.1, gives the user a chance to notice servers that do not belong to their provider.¶

An attacker-controlled configuration could also point a protocol's URL at a host that redirects the user agent elsewhere. Section 7.5 describes the constraints that user agents apply when following such redirects, including that the user confirms the host reached after all redirects rather than the host named in the configuration.¶

None of this is sufficient on its own. The user agent also needs to combine these mechanisms with a conservative trust policy for its TLS when retrieving the JSON configuration.¶

7.3. DNS

The value of the digest validation described in Section 5.2.2 is that it ties the configuration to the operator of the domain's DNS zone, rather than to whoever operates the host that serves the well-known URI. An attacker who can serve content for ua-auto-config.{domain} (for example by compromising a hosting provider or a content delivery network configuration), but who cannot publish records in the domain's zone, cannot make a substituted configuration validate.¶

That property only holds if the DNS answer itself is trustworthy, so a user agent that performs this validation needs to take care that an attacker has not altered the DNS response. Using DNSSEC is one method of improving the security aspects of this approach, as is querying a trusted resolver over a channel that provides integrity protection, such as DNS over TLS or DNS over HTTPS. An attacker who can alter DNS responses but cannot defeat the requirements in Section 7.4 can cause the validation to fail for a legitimate configuration, and thereby prevent automatic configuration.¶

For this reason, Section 5.2.2 states this validation as a SHOULD rather than a MUST: a user agent that has no way to obtain DNS answers that it can rely on MAY omit it. Such a user agent relies solely on the transport security requirements in Section 7.4 and Section 7.4.1, under which the configuration is retrieved over TLS from a host under the domain of the user's email address with the server certificate validated, together with the user confirming the resulting server names (Section 5.5).¶

7.4. Transport Security Validation

Whenever secure transport is used (including TLS for HTTPS connections and QUIC's TLS-based security layer for HTTP/3), user agents MUST check the certificates presented by the server. This certificate MUST be within its validity period (prior to its expiration date) and MUST chain to a root CA that is trusted by the user agent. The certificate MUST have a subject alternative name (SAN) ([RFC5280]) with a DNS-ID ([RFC9525]) matching the hostname, per the rules given in [RFC9525]. The certificate MAY also be checked for revocation via OCSP ([RFC6960]), CRLs ([RFC5280], updated by [RFC6818]), or some other mechanism. The general recommendations for the secure use of TLS in [RFC9325] SHOULD be followed.¶

If these checks fail or the server certificate is otherwise invalid, the user agent MUST disconnect and MUST NOT use any configuration retrieved from that URI.¶

Certificate validation failures represent significant security risks, as they may indicate attempts to redirect users' credentials to an attacker. User agents SHOULD NOT allow users to override certificate validation checks.¶

Beyond the minimum TLS version required in Section 7.4.1, user agents MAY implement even more restrictive transport security policies for the connections described in this document than those typically required for web browsing, in order to provide stronger security guarantees. For TLS connections, user agents MAY want to further restrict the allowed cipher suites. For QUIC connections, user agents MAY apply similar restrictions to the underlying TLS handshake parameters.¶

7.5. Following HTTP Redirects

Several steps of the mechanism described in this document involve HTTP requests that a server can answer with a redirect (any of the 3xx status codes described in Section 15.4 of [RFC9110]). This includes retrieval of the JSON configuration (Section 5.2.1), the HTTP authentication probes (Section 5.4.2), and connections that the user agent makes to OAuth endpoints (Section 5.4.1). Allowing redirects lets a provider publish a stable URL in the configuration that acts as a "front door" and redirects the user agent to the server that actually handles a protocol.¶

Redirects are, however, a security-sensitive feature. The configuration is treated as potentially attacker-influenced (Section 7.2), and a redirect can send a probe, and subsequently the user's credentials, to a host that never appeared in the configuration and that the user was never shown. User agents therefore MUST apply the following constraints whenever they follow a redirect for any request described in this document.¶

1. Every hop in the redirect chain MUST use the https scheme and MUST be secured using TLS 1.3 ([RFC8446]) or higher, with certificate validation enforced independently for each hop, as required by Section 7.4.1.¶
2. The user agent MUST limit the number of redirects it follows for a single request. This limit MUST NOT exceed 5. If a request would exceed this limit, the user agent MUST NOT follow the additional redirect and MUST abort the operation, discarding any data obtained from that redirect chain.¶
3. The hostnames that the user agent presents to the user for confirmation (Section 5.5), and that it will authenticate with, MUST be the hostnames of the servers reached after all redirects have been followed, not the hostnames taken from the configuration. If following a redirect changes the host that the user agent will authenticate with, the user agent MUST present that final host for confirmation before any credentials are sent to it.¶

Because the user agent probes each server of interest (Section 5.4.2) before it asks the user to confirm the server hostnames (Section 5.5), the final host reached after any redirect is known at the time of confirmation.¶

7.6. Updating the Configuration

The mechanism described in this document can be used to upgrade a user's configuration. The user agent could check for configurations even when it has a working configuration for an account. If the user agent finds a configuration that is better (in some way) than the already existing configuration, it could then upgrade the existing configuration.¶

But in doing so, the user agent would increase the attack window that a potential attacker has. Instead of only giving an attacker the opportunity when the user configures their user agent for the first time, the attacker would now have an opportunity each time the user agent checks for a better configuration. That could be undesirable.¶

7.7. Provider Information

Image parsers are a common attack vector, and user agents MUST NOT display the logo images described in Section 4.4.1 unless they can do so in a way that doesn't expose the user agent to such attacks.¶

Retrieving a logo also discloses information to whoever operates the host that the url of that logo names. That host learns the user agent's IP address, and the fact that this user agent is being set up for this provider, at the time of setup. The host can be operated by a third party, such as a content delivery network, and the configuration is treated as potentially attacker-influenced (Section 7.2), so the url can name a host that the user has no relationship with and has not been shown. User agents therefore SHOULD NOT retrieve logo images before the user has confirmed the configuration as described in Section 5.5, and MAY choose not to retrieve them at all. Providers SHOULD serve logo images from a host under the same registrable domain as the configuration document itself.¶

8.1. The User-Agent Auto-Configuration Protocol Registry

This document establishes the user-agent auto-configuration protocol registry.¶

User-agent auto-configuration protocols are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with Specification Required (using terminology from [RFC8126]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.¶

Registration requests are sent to the art@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for user-agent auto-configuration protocol: example").¶

TODO: confirm the review mailing list for this registry. This document currently names art@ietf.org; the working group may instead want to request a dedicated review list.editor¶

Before a period of 14 days has passed, the Designated Expert(s) will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.¶

Registry Name:

User-Agent Auto-Configuration Protocols¶

Registration Procedure:

Specification Required (per [RFC8126])¶

8.2. Registration