Well-Known Uniform Resource Identifiers (URIs)
draft-nottingham-rfc5785bis-11

Thanks for taking the time to update RFC 5785 to match the needs of modern
HTTP-using protocols. This will make my job much easier. :)

---------------------------------------------------------------------------

§3.1:

>  Change controller:  For Standards-Track RFCs, state "IETF".  For
>     others, give the name of the responsible party.  Other details
>     (e.g., postal address, e-mail address, home page URI) may also be
>     included.

The IANA recently went through an exercise for the ITAD registry in which it
decided to no longer collect postal addresses for registrants, and to purge
those addresses it had already collected. I believe that the interpretation of
GDPR they have arrived at is that, absent a clearly stated reason to possess it,
they no longer wish to receive such information at all. I would suggest removing
it from the list of details that change controllers may optionally submit.

---------------------------------------------------------------------------

§3.1:

>  General requirements for registered relation types are described in
>  Section 3.

I don't think you mean "relation types" here.

---------------------------------------------------------------------------

§4.1:

>  o  Using an application-specific media type in the Content-Type
>     header, and requiring clients to fail if it is not used

Nit: "...header field..." (I know, but this is where we are today)

Alissa and Spencer already captured all of my comments :-)

Thanks for doing this document. I have comments. 

The document says this: 

   Applications that wish to mint new well-known URIs MUST register
   them, following the procedures in Section 5.1.

   For example, if an application registers the name 'example', the
   corresponding well-known URI on 'http://www.example.com/' would be
   'http://www.example.com/.well-known/example'.

but almost immediately says this:

   Registered names for a specific application SHOULD be correspondingly
   precise; "squatting" on generic terms is not encouraged.  For
   example, if the Example application wants a well-known location for
   metadata, an appropriate registered name might be "example-metadata"
   or even "example.com-metadata", not "metadata".

ISTM that this isn't a BCP14 SHOULD - it's not required for interworking, and I have no idea what "correspondingly precise" would mean as a normative requirement, but more to the point, if you moved the example below this paragraph, and used one of the correspondingly precise versions as your example, that would likely help people assimilate this excellent advice.

And, now that I'm looking at this more closely, ISTM that the beginning of Section 3 is intended for requesters, most of Section 3 is intended for expert reviewers, and Section 3.1 is intended for requesters. Perhaps putting all the information intended for requesters in one place and clearly labeling the audiences would be helpful?

I'm looking at this text in Section 3.1,

   Standards-defined values have a status of "permanent".  Other values
   can also be registered as permanent, if the Experts find that they
   are in use, in consultation with the community.  Other values should
   be registered as "provisional".

   Provisional entries can be removed by the Experts if - in
   consultation with the community - the Experts find that they are not
   in use.  The Experts can change a provisional entry's status to
   permanent at any time.

   Note that well-known URIs can be registered by third parties
   (including the expert(s)), if the expert(s) determines that an
   unregistered well-known URI is widely deployed and not likely to be
   registered in a timely manner otherwise.  Such registrations still
   are subject to the requirements defined, including the need to
   reference a specification.

and, call me cynical, but this seems to be begging people to squat, because if they achieve wide deployment, their well-known URI will likely be be eventually registered (and, unless I'm missing something, may be registered as "permanent") with no interaction with expert reviewers, and if they don't achieve wide deployment, squatting didn't matter. 

What we're doing with https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml ia tracking "unauthorized use reported". If the experts can chase down a specification for an unregistered use and process it with themselves as requesters, that's great, but if they can't always do that, you might consider adding "unauthorized" or "reported unregistered use", or something like that, as a third Status value. 

But do the right thing, of course :-) ...