Skip to main content

Defining Well-Known Uniform Resource Identifiers (URIs)
RFC 5785

Revision differences

Document history

Date Rev. By Action
2020-01-21
05 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
05 (System) Notify list changed from mnot@pobox.com, eran@hueniverse.com, draft-nottingham-site-meta@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2010-04-06
05 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-04-06
05 Cindy Morgan [Note]: 'RFC 5785' added by Cindy Morgan
2010-04-06
05 (System) RFC published
2010-01-21
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-01-21
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-01-21
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-01-20
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-01-12
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-01-11
05 (System) IANA Action state changed to In Progress
2010-01-11
05 Cindy Morgan IESG state changed to Approved-announcement sent
2010-01-11
05 Cindy Morgan IESG has approved the document
2010-01-11
05 Cindy Morgan Closed "Approve" ballot
2010-01-11
05 Lisa Dusseault State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lisa Dusseault
2010-01-11
05 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2010-01-10
05 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2010-01-04
05 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2009-12-29
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-12-29
05 (System) New version available: draft-nottingham-site-meta-05.txt
2009-12-17
05 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2009-12-17
05 Cullen Jennings
[Ballot discuss]
I plan to put a YES on this fine document which will no doubt result in a very substantial change to what is …
[Ballot discuss]
I plan to put a YES on this fine document which will no doubt result in a very substantial change to what is possible on the world wide web but I think it needs one clarification first. I'd like the document to make it clear that this applies not only to meta data but also the URLs for HTTP APIs. It will help interoperability of these APIs to have them at well known APIs. If you disagree with this, then I have lots of questions about how meta data is somehow different than the API use case.
2009-12-17
05 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2009-12-17
05 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-12-17
05 Dan Romascanu
[Ballot discuss]
This document looks fine with me, and I will clear my DISCUSS if IANA is certain that they know what to do, but …
[Ballot discuss]
This document looks fine with me, and I will clear my DISCUSS if IANA is certain that they know what to do, but I think that there two of the paragrasphs in the IANA COnsiderations section are slightly unconsistent:

> Well-known URIs are registered on the advice of one or more
  Designated Experts (appointed by the IESG or their delegate), with a
  Specification Required (using terminology from [RFC5226]).

>  Registration requests consist of the completed registration template
  (see Section 5.1.1), typically published in an RFC or Open Standard
  (in the sense described by [RFC2026], section 7).  However, to allow
  for the allocation of values prior to publication, the Designated
  Expert(s) may approve registration once they are satisfied that an
  RFC (or other Open Standard) will be published.

RFC 5226 does not refer to an Open Standard as per RFC 2026 (supplementary to an RFC)when refering to a Specification, but rather uses the term "permanent and readily available". Experts usually interprete this as accepting specifications that are not issued by an SDO as ITU-T, IEEE, ANSI examples used by 2026. Is the intention here to be more restrictive than 5226 and recommend using only SDO issued 'Open Specifications'?
2009-12-17
05 Dan Romascanu
[Ballot discuss]
This document looks fine with me, and I will clear my DISCUSS if IANA is certain that they know what to do, but …
[Ballot discuss]
This document looks fine with me, and I will clear my DISCUSS if IANA is certain that they know what to do, but I think that there two of the paragrasphs in the IANA COnsiderations section are slightly unconsistent:

> Well-known URIs are registered on the advice of one or more
  Designated Experts (appointed by the IESG or their delegate), with a
  Specification Required (using terminology from [RFC5226]).

>  Registration requests consist of the completed registration template
  (see Section 5.1.1), typically published in an RFC or Open Standard
  (in the sense described by [RFC2026], section 7).  However, to allow
  for the allocation of values prior to publication, the Designated
  Expert(s) may approve registration once they are satisfied that an
  RFC (or other Open Standard) will be published.

RFC 5226 does not refer to an Open Standard as per RFC 2026 (supplementary to an RFC)when refering to a Specification, but rather uses the term "permanent and readily available". Experts usually interprete this as accepting specifications that are not issued by an SDO as ITU-T, IEEE, ANSI examples used by 2026. Is the intention here to be more restrictive than 5226?
2009-12-17
05 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-12-17
05 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2009-12-16
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-12-16
05 Amy Vezza State Changes to IESG Evaluation from IESG Evaluation - Defer by Amy Vezza
2009-12-11
05 Robert Sparks
[Ballot discuss]
Before approving this document, I would like a short discussion
with the IESG on the points below.

This document represents a significant deviation …
[Ballot discuss]
Before approving this document, I would like a short discussion
with the IESG on the points below.

This document represents a significant deviation from the
conventional wisdom and long standing consensus around where
control for the assignment of URIs to resources lives.
The change will have a huge impact on client, server, and
application code. It will also impact server and
application policy.

This will put us on course for a web full of
conventions and expectations like:
https://www.example.com/.well-known/login
https://www.example.com/.well-known/shopping-cart

My initial (very negative) reaction to the draft was informed by
the earlier consensus. That said, the draft presents an informed
discussion of the tradeoffs made by taking this path, and it
does appear to scratch a real and spreading itch:
(Anecdote: Adam points to Thunderbird's use of
https://autoconfig.(hostname)/mail/mozilla.xml
deep in it's non-user-configurable javascript code)

So, I am willing to ballot No Objection, but would like to first talk through these points:

1) There is some legacy text capturing the earlier wisdom that
  will have to be adjusted.  Has there been any activity yet
  to identify the places that need touching and to start the
  change process?  (I'm looking at things like
  http://www.w3.org/TR/webarch/#uri-assignment
  for example).

2) As a quick sanity-check, could we talk through whether the
  review of this document so far has been sufficiently broad
  that we are unlikely to surprise anyone here, in the w3c, or
  elsewhere that we shouldn't have surprised with a statement
  of IETF consensus?
2009-12-11
05 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2009-12-04
05 (System) Removed from agenda for telechat - 2009-12-03
2009-12-03
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sandra Murphy.
2009-12-02
05 Robert Sparks State Changes to IESG Evaluation - Defer from IESG Evaluation by Robert Sparks
2009-12-02
05 Lars Eggert
[Ballot comment]
Section 5.1., paragraph 4:
>    Registration requests should be sent to the [TBD]@ietf.org mailing
>    list for review and comment, with …
[Ballot comment]
Section 5.1., paragraph 4:
>    Registration requests should be sent to the [TBD]@ietf.org mailing
>    list for review and comment, with an appropriate subject (e.g.,
>    "Request for well-known URI: example").

  I question the need to involve a list here - do we really expect such
  a volume of requests? I think normal Expert Review is sufficient.
2009-12-02
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-12-02
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2009-12-02
05 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-12-02
05 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-12-01
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-12-01
05 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-11-30
05 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel
2009-11-30
05 Adrian Farrel [Ballot comment]
Section 1
You might usefully include a reference for the Robots Exclusion Protocol
2009-11-22
05 Alexey Melnikov
[Ballot comment]
I voted Yes for this document, but please consider if the following comments are worth addressing:

1.  Introduction

  While there are several …
[Ballot comment]
I voted Yes for this document, but please consider if the following comments are worth addressing:

1.  Introduction

  While there are several ways to access per-resource metadata (e.g.,
  HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
  associated with them often precludes their use in these scenarios.

I would personally like to see an expanded version of this statement.
In particular "perceived overhead for whom" and why is it perceived.

3.  Well-Known URIs

  Note that this specification also does not define a format or media-
  type for the resource at located at "/.well-known/" and clients

I think the first "at" should be dropped.

  should not expect a resource to exist at that location.

5.1.  The Well-Known URI Registry

  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.

Personally I prefer to have 2 periods - the expect review period and the maximum review period after which the requester can complain. This is what
I used in one of my documents (6 weeks is the upper bound in this case):

  Expert Reviewer should strive for timely reviews.  Expert Reviewer
  should take no longer than 6 weeks to make and announce the decision,
  or notify the mailing list that more time is required.

  Decisions (or lack of) made by an Expert Reviewer can be appealed to
  the IESG.


5.1.1.  Registration Template

  Change controller:  For standards-track RFCs, state "IETF".  For
      other open standards, give the name of the publishing body (e.g.,
      ANSI, ISO, ITU, W3C, etc.).  A postal address, home page URI,
      telephone and fax numbers may also be included.

Question: can a new well-known URI be registered by an individual person and not an SDO?
I.e. is it Ok for a reviewer to say "you are not an SDO, publish an RFC or go away"?
2009-11-22
05 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded by Alexey Melnikov
2009-11-20
05 Lisa Dusseault [Ballot Position Update] New position, Yes, has been recorded for Lisa Dusseault
2009-11-20
05 Lisa Dusseault Ballot has been issued by Lisa Dusseault
2009-11-20
05 Lisa Dusseault Created "Approve" ballot
2009-11-20
05 Lisa Dusseault Placed on agenda for telechat - 2009-12-03 by Lisa Dusseault
2009-11-20
05 Lisa Dusseault State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Lisa Dusseault
2009-11-19
04 (System) New version available: draft-nottingham-site-meta-04.txt
2009-11-06
05 Amanda Baber
IANA comments:

IESG Note: Expert Designation Required

Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: Well-Known URI Registry …
IANA comments:

IESG Note: Expert Designation Required

Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: Well-Known URI Registry
Registration Procedures: Designated Expert with Specification Required

Initial contents of this registry will be:

[empty]

We understand the above to be the only IANA Action for this document.
2009-11-06
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-10-09
05 Amy Vezza Last call sent
2009-10-09
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-10-09
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sandra Murphy
2009-10-09
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sandra Murphy
2009-10-08
05 Lisa Dusseault Last Call was requested by Lisa Dusseault
2009-10-08
05 Lisa Dusseault State Changes to Last Call Requested from Publication Requested by Lisa Dusseault
2009-10-08
05 (System) Ballot writeup text was added
2009-10-08
05 (System) Last call text was added
2009-10-08
05 (System) Ballot approval text was added
2009-09-29
05 Lisa Dusseault Draft Added by Lisa Dusseault in state Publication Requested
2009-09-17
03 (System) New version available: draft-nottingham-site-meta-03.txt
2009-07-12
02 (System) New version available: draft-nottingham-site-meta-02.txt
2009-02-10
01 (System) New version available: draft-nottingham-site-meta-01.txt
2008-10-16
00 (System) New version available: draft-nottingham-site-meta-00.txt