Defining Well-Known Uniform Resource Identifiers (URIs)
draft-nottingham-site-meta-05

[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.

[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'?

[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?

[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?

[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.

[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"?

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.