Changing requirements for Well-Known URIs

[mnot]

with my IETF Liaison hat on; cc @wseltzer

Several years ago, the IETF published RFC5785 in consultation with the W3C TAG, to establish the Well-Known URI registry.

At the time, the shared understanding was that the purpose of well-known URIs was to discover so-called "site-wide metadata"; i.e., information that applied to the origin it was hosted on.

More recently, there have been an accelerating number of registration requests -- including from IETF Working Groups -- for entries that do not meet this intended use; rather, they are often to "bootstrap" a new protocol.

For example, the DOH Working Group is creating a way to do DNS lookups over a HTTPS resource, for improved privacy and other benefits. While they could start the protocol with a URI, many feel that it would be easier if a well-known location is used, so that the protocol could be started with a bare hostname -- an artefact that end users are more familiar with.

Another tension comes from requests to allocate new TCP port numbers for protocols that use HTTP as a substrate. Many such protocols are bootstrapped from a hostname and not an URI.

The Service Name and Transport Protocol Port Number Registry Expert Review team is concerned about preservation of TCP ports which is much more limited resource space that .well-known URI prefix namespace. Designated Experts for the Ports and Service registry are occasionally recommending use of .well-known URI prefixes instead of allocating new TCP port numbers.

While standardising these URIs are arguably a violation of the Architecture of the World Wide Web, in that they are usurping the origin server's authority over its own resources, doing so within the defined "sandbox" of the well-known URI space limits the harm and does not compete with other uses (in that the space is managed by a registry, and already cannot be used by sites).

However, our current reading of RFC5785 disallows these uses, so we have been refusing these registrations. Some in the community have questioned whether this harm is significant enough to preclude registration.

As a result, the IETF is considering starting work in this area to revise the registration criteria for the Well-known URI registry. We would appreciate feedback from the TAG (or other parts of the W3C) regarding the following questions:

1. Is the use of well-known URIs for purposes other than resources about the origin itself of concern to the TAG, especially from a Web architecture perspective? If so, please explain why, or provide references.

2. Are there criteria that the TAG believes should be imposed upon well-known URI registrations? If so, what and why?

3. If the IETF were to embark upon work to revise the registration policy for well-known URIs, would the TAG want to be involved in that process (e.g., by having one or more individuals participate in the discussion)?

We intend to make a decision about this work soon, so would appreciate a timely response.

[torgo]

Discussed in tokyo f2f. Resolution was : “We don't think .well-known is best place to do boot-strapping. We propos SRV - if there needs to be extra structured data-or sub-origins then .well-known is an option.”

[mnot]

Thanks, but SRV is seen as many as difficult or impossible to deploy.

To be clear - this was not a request for advice for the best way to do bootstrapping. We're looking to the TAG here for information about whether using .well-known for other use cases causes active harm to the Web, or other architectural concern; not for suggestions for alternatives.

My take-away from the conversation was that the biggest concern was around security, and that the TAG didn't have architectural concerns here.

[hadleybeeman]

On the architectural front: well-known does go against the architecture of the web - designating URLs do in fact take away the origin's authority to designate its own resources. I (generally) understand why we have the well-known URIs that we have, but it would be good to emphasise that they are the exception, and new ones should be used sparingly.

[hadleybeeman]

Otherwise I think we're done here. Thanks @mnot!